Refactor geojson creation in Minerva

[aashish24]

[aashish24]

We have few issues related to GeoJSON and Minerva. GeoJSON is a very important format for Minerva. So I would like to fix the following issues for now:

• Use earcut for triangulation - GeoJS related issue
• GeoJS reader that can read single of multi [points, lines, polygons] and convert them into multiple features each sharing the common property object (hopefully not by visualization attributes since that could change via mapping) . All of these features should be part of a single layer (I believe QGIS does the same thing).
• Minerva backend uses vector tile layers and or stream Geojson using geobuf

[aashish24]

any geojson --> (minerva --> adapter) --> geojs-friendly-geojson --> geojs

[aashish24]

• Use earcut for triangulation - GeoJS related issue
• (minerva --> adapter) --> Will convert into FeatureCollection spec of GeoJSON
• We will need fast rendering of GeoJSON in GeoJS

[jbeezley]

I created https://github.com/OpenGeoscience/geojs/pull/556 to address this issue. It should take care of the worst of the performance problems by no longer generating multiple feature objects.

After doing some more thinking (and experimenting), I don't think there is much use for creating a "reduced" geojson specification as I proposed last week. What I was trying to get at was avoiding copying the data when assembling the features internally. This would be possible using the d3 renderer, but for GL, we need to assemble the VGL buffers and do other processing on the data (such as triangulation), so copying the data is unavoidable at the moment. If want to avoid the overhead of copying data arrays in the future, we will have to talk about a lower level interface to our feature classes that accept raw buffers (typed arrays) rather than JSON derived objects.

I think the big unknown at the moment is how we handle styling features from GeoJSON. I baked in the ability to provide styles statically in the property objects ({"fillColor": "red"}, etc), but how a "mapper" class would interact with the current reader is an open question.

Finally, we should look into simplifying the geometries at some point in the pipeline. People will always attempt to load an unrealistically large files... we don't want to crash their browser. For point features, we can do sampling and clustering. For polylines, there is simplifyjs.

[aashish24]

After doing some more thinking (and experimenting), I don't think there is much use for creating a "reduced" geojson specification as I proposed last week. What I was trying to get at was avoiding copying the data when assembling the features internally. This would be possible using the d3 renderer, but for GL, we need to assemble the VGL buffers and do other processing on the data (such as triangulation), so copying the data is unavoidable at the moment. If want to avoid the overhead of copying data arrays in the future, we will have to talk about a lower level interface to our feature classes that accept raw buffers (typed arrays) rather than JSON derived objects.

I agree.

I think the big unknown at the moment is how we handle styling features from GeoJSON. I baked in the ability to provide styles statically in the property objects ({"fillColor": "red"}, etc), but how a "mapper" class would interact with the current reader is an open question.

Finally, we should look into simplifying the geometries at some point in the pipeline. People will always attempt to load an unrealistically large files... we don't want to crash their browser. For point features, we can do sampling and clustering. For polylines, there is simplifyjs.

+1.

[matthewma7]

@aashish24 @jbeezley @manthey Is this still a valid issue?