-
Notifications
You must be signed in to change notification settings - Fork 93
[change] Uniform geojson map rendering #396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Updated the Echarts rendering logic to wrok with
Updated the Echarts rendering logic to wrok with
[fix] Updated the Echarts rendering
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be moving in the right direction, I guess we can remove marker cluster now, right?
QA checks and CI builds are failing, please fix.
See my comments below.
src/js/netjsongraph.core.js
Outdated
// clustering and ECharts overlays. | ||
this.originalGeoJSON = JSON.parse(JSON.stringify(JSONData)); | ||
JSONData = this.utils.geojsonToNetjson(JSONData); | ||
this.type = "netjson"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the point of keeping this stuff and keep all the if statements if the value is always netjson
?
We should be able to simplify the code and remove the useless if statements. I wouldn't change the type of the object, it feels wrong to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still see this.type = "netjson";
here, why?
Is it really necessary to change it?
[fix] Updated Test Cases
This reverts commit 59bf856.
Uniform geo json map rendering
Streamline map rendering
Simplifies the data pipeline by converting GeoJSON input to NetJSON early and treating all data as NetJSON internally. Removes legacy GeoJSON-specific branches, updates appendData logic, and adjusts tests to match the unified approach. This improves maintainability and consistency in map rendering and data updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please squash the commits in this PR into one commit so that it will be easier to manage with #349.
…sp/netjsongraph.js into stramlining-map-rendering
Streamlines the map rendering logic for GeoJSON and NetJSON data types and removes the marker-cluster dependency. Closes #395.
…sp/netjsongraph.js into stramlining-map-rendering
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some questions below.
src/js/netjsongraph.render.js
Outdated
self.originalGeoJSON = JSON.parse(JSON.stringify(JSONData)); | ||
JSONData = self.utils.geojsonToNetjson(JSONData); | ||
// From this point forward we treat the data as NetJSON | ||
self.type = "netjson"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried removing this and the geojson example continues working without errors, are you sure it's necessary? It feels wrong to me. You have already cleand up the code which was checking whether type is netjson, we assume there's only one way to load data now, why is this still necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the code is not only checking if type is NetJSON it also preserve the original GeoJSON via self.originalGeoJSON to still render polygons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am asking to avoid changing the type
here, but change any other code that relies on type
being netjson
so that we assume the type is always netjson
.
Extracted all GeoJSON-specific logic into src/js/netjsongraph.geojson.js for better maintainability and clarity. Updated the public API to forward geojsonToNetjson calls to the new helper. Refactored map rendering to use addPolygonOverlays for displaying Polygon and MultiPolygon features on Leaflet. Updated documentation to reflect these changes and improve clarity on GeoJSON support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed all the changes Kindly let me know if any other changes are required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still see type
being changed in a couple of places which I explained I feel it's wrong and we shouldn't do it, see my comments below.
src/js/netjsongraph.core.js
Outdated
// clustering and ECharts overlays. | ||
this.originalGeoJSON = JSON.parse(JSON.stringify(JSONData)); | ||
JSONData = this.utils.geojsonToNetjson(JSONData); | ||
this.type = "netjson"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still see this.type = "netjson";
here, why?
Is it really necessary to change it?
src/js/netjsongraph.render.js
Outdated
self.originalGeoJSON = JSON.parse(JSON.stringify(JSONData)); | ||
JSONData = self.utils.geojsonToNetjson(JSONData); | ||
// From this point forward we treat the data as NetJSON | ||
self.type = "netjson"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am asking to avoid changing the type
here, but change any other code that relies on type
being netjson
so that we assume the type is always netjson
.
Updates NetJSONGraph to retain 'geojson' as the public-facing type when loading GeoJSON data, instead of converting it to 'netjson'. Adjusts related rendering logic and tests to reflect this change.
Noted and addressed in 5d63609 now we don't explicitly change the type to netJSON from geoJSON we just assume it's netJSON. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On master:

On this branch:

The Polygon is drawn in a way that makes it look as if there were additional points drawn on the map, which shouldn't happen.
Can you please edit the sample data to make sure we have at least one geojson geometry of each type supported?
This way we can make sure they all look as they should. Use a geojson visualizer (like the one here on github) to see how each standard geojson geometry should look like.
Added MultiPoint, LineString, MultiLineString, and MultiPolygon features to the GeoJSON sample data for broader geometry coverage. Refactored geometry handling in netjsongraph.geojson.js by removing unused Polygon and MultiPolygon processing code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's almost there but I still see a few details to adjust, let's compare the output of the github visualizer and https://geojson.io.
This is the current sample data visualized with the current implementation:

This is the github visualizer:

Which can be viewed by opening: https://github.com/openwisp/netjsongraph.js/blob/7cdb431162dfed76c5dac3eb39429efbaebbb067/public/assets/data/geojson-sample.json
This is the geojson.io visualizer (copy/paste the example data):

Now let's Observe the key differences:
- The other visualizers don't use circles to highlight the coordinates, shapes are just drawn
- The visualizers automatically center the view based on the data being shown, bounds are calculated and map center and zoom are automatically calculated so that the view is able to show everything when the map is loaded. This is very important, please make sure the library is able to behave identically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.

-
I noticed that some output values appear as
[Object, Object]
. Please add a few more sample properties and ensure all are shown correctly (please add an assertion in the tests for this). -
Let's treat
properties.name
as a special case and convert it as netjson label (needs assertion in tests). -
Can we convert lines and multi line strings as links in netjson? (needs assertion in tests)
-
Please add some
id
elements to the sample data and verify with an assertion that is converted in netjson format. -
Where is the value
Gjn_4
coming from? I don’t see any corresponding entry in the data sources. This random stuff shouldn't appear, make sure there's some test data which doesn't have any name, id or property defined and have an assertion to verify these random names are not shown.
Checklist
Reference to Existing Issue
Closes #395 .
Description of Changes
Streamed line map rendering logic for GeoJSON and NetJSON map data type
Screenshot
Please include any relevant screenshots.