1

I have a HTML page with an image viewer and a leaflet map. For each image, I have some information, like upper left corner pixel coordinates, real size of each pixels, etc.

I want to have access to them, to print them under the image viewer in HTML.

This information is actually stored in text files, but as my app need to work from a USB key and not localhost, there is a security problem. Importing files via input isn't viable either because of the quantities of images (~100,000) and therefore text files. If possible, I would like to only have the info of the current visible image loaded in order to avoid memory problems.

As I'm using leaflet, i have a GeoJSON file where I can easily add and store this information, but I don't know how to get them back on need.

Here is a view of my GeoJSON:

var point_layer_WGS84_dist = {
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },

"features": [
{ "type": "Feature", "properties": { "x": 7.6789651, "y": 48.5066953, "distCoupe": 10000, "path": "coupes_10000_14995\\PM_10000.png" }, "geometry": { "type": "Point", "coordinates": [ 7.6789651, 48.5066953 ] } },
{ "type": "Feature", "properties": { "x": 7.6788011, "y": 48.5063054, "distCoupe": 10045, "path": "coupes_10000_14995\\PM_10045.png" }, "geometry": { "type": "Point", "coordinates": [ 7.6788011, 48.5063054 ] } },

So here are my questions :

1) Is there different solution for storing the information and using them in the JavaScript?

2) About the GeoJSON, is there a possibility like:

var feat = point_layer_WGS84_dist.getFeatureByPropertie("distCoupe",'10000')
var imageLocation = feat.path

*

EDIT FOR ANSWERING 2)

//création des variables globales d'info image
var x;
var y ;

//fonction de récupération des informations de l'image active depuis le geoJSON
function loadProperties(dist){
point_layer_WGS84_npix.getFeaturesByProperty = function(key, value) {
    return this.features.filter(function(feature){
        if (feature.properties[key] === value) {
            return true;
        } else {
            return false;
        }
    });
};

var feats = point_layer_WGS84_npix.getFeaturesByProperty('distCoupe', dist);
x = feats[0].properties.x;
y = feats[0].properties.y;

with this solution i can access to a geojson file linked ith the html as a .js file. This allows me to avoid security problems for calling local files as .js are accepted.

1

1) Mapperz suggests lightweight databases and this is a good solution, especially in your case a NoSQL database, which is all you need. A solution with great potential is to leverage the HTML5 standard and implement an IndexedDB (which is akin to a NoSQL database and specifically designed to work with HTML5). To make life easy there is a JavaScript library available to help with this - see BakedGoods and a tutorial on IndexedDB here.

2) Yes you can do something like that. The simplest way is in your OnEachFeature function, have a line that adds your properties to the layer:

layer.properties = feature.properties;

However, this will add everything and you don't need your x and y attributes as they are part of the geometry, so I'd refine the code to only add the bits I want. By restricting the information you store to only what you want, you should be able to handle your points (as you are loading 100,000 anyway. So, maybe limit it to just the information you need:

layer.path = feature.properties.path;

Then an on-click event on the layer could be made to return the path. To do the search you can maintain a simple Object that relates layer and distCoupe:

var imgLayers = {};  //global or high-level object
imgLayers [feature.properties.distCoupe] = layer;  //this goes in the OnEachFeature function to add a reference to the current layer to your object.

Then you can look-up in your object like this:

result = imgLayers ['10000'];
myPath = result.path;

However, if you are using IndexedDB or Mongo or something like that (as per #1), you do not need all of this - you can just look up in the database. So, I'd implement one or the other. #2 is less elegant but simpler. #1 will handle more data, is more elegant but is harder to implement.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.