6

I noticed in my map that when I export to GeoJSON, some smaller feature have their coordinates shifted. I have set the export COORDINATE_PRECISION to 99 (max), tried various coordinate systems but no luck. In QGIS my layer coordinate systems are 3857 and I export to 4326.

Here are the map in QGIS:

enter image description here

Here is the imported GeoJSON in Mapbox (the result is the same in geojson.io and others)

enter image description here

To eliminate project setting errors, I've started a fresh new project. Then added OpenStreetMap layer with coordinate system 3857. Then created a new shapefile layer with the same coordinate system and drew parallel rectangles. With just an export to 4326 GeoJSON, the rectangles get distorted.

enter image description here

I also exported via online Shapefile to GeoJSON converter using ogre.adc4gis.com to eliminate QGIS export function having a problem during projection, but the result is the same.

Edit 1: Following Jakob Miksch's comment, I created a new shapefile layer with EPSG:4326. I exported it and in most cases this fixed the issue. However, minor inconsistencies are still there as below. The inconsistencies mostly happen in certain areas of the building.

enter image description here

enter image description here

Edit 2: Here is the shapefile I've been working on: Shapefile

Edit 3: Switching the coordinate system to custom system centered on the location I'm working on seems to help a little bit with the output, but I still see interest challenges. For example, here, all these boxes share an edge (from a guideline), but the box above doesn't have the middle vertex, and therefore is straight, while, the top vertex of the smaller boxes below utilize a slightly off vertex. Interestingly, if I recreate the box above, but add a vertex, it removes those ugly overlaps (still not everything is perfectly parallel, however).

enter image description here

Edit 4: Here is my latest GeoJSON file. It utilizes the custom coordinate system as recommended here, which minimizes the errors significantly. However in other renderers outside of QGIS (geojson.io, MapBox), the edges won't remain parallel/perpendicular.

demir
  • 111
  • 4
  • 3
    COORDINATE_PRECISION is usualy number of decimal places, 99 is overkill. Maybe try something reasonable like 5-15.

    What happens when you re-import the GeoJSON back into QGIS. That's important to check that the problem is coming from exporting from QGIS and not importing into geojson.io and Mapbox.

     – AndrewHarvey Oct 25 '19 at 06:51
  • 3
    in general EPSG:3857 should only be used for displaying. Your data should never be in this coordinate reference system. It's better if you create your new layer in EPSG:4326 and then export it to GeoJSON. – Jakob Miksch Oct 25 '19 at 07:40
  • 3
    It would be useful to get a sample of original data and converted data. – user30184 Oct 25 '19 at 11:47
  • @JakobMiksch as in my edit above, your suggestion mostly fixed but small inconsistencies are there still. – demir Oct 25 '19 at 21:24
  • 1
    It seems to me a precision error in the QGIS digitizing tools, which I don't know if you can have control. Being the area so small, I find it strange that angular differences are noticed between an equirectangular and a pseudo Mercator projection. Anyway, I do not understand who prefers to draw parallel and perpendicular lines in the equirectangular one. – Gabriel De Luca Oct 25 '19 at 22:11
  • @GabrielDeLuca would a better approach be to switch to 4326 display and trace the entire building and the interiors without any parallel/perpendicular lines? – demir Oct 25 '19 at 23:26
  • Also to further clarify, same issue happens when I use ogr2ogr or if I import Shapefiles to Mapbox directly. – demir Oct 26 '19 at 00:48
  • 1
    Not really. It is best to digitize in a conformal projection system (transverse Mercator, for example) to preserve the angles, customized (with the meridian of tangency within your work area) so as not to distort the distances so much. Once the digitization is done, reproject the vector features to the system that best suits your next stage of visualization. I am analyzing your other question to write an answer that addresses this and the precision of the QGIS digitization tools. Honestly, sample data to analyze and repeat the inconvenience would help. – Gabriel De Luca Oct 26 '19 at 00:52
  • I've added the shapefile to the question above. With a fresh QGIS project, I can add OpenStreetMap layer, then import that shapefile and it will display accurately. If I export it to GeoJSON (in QGIS or any other way), it will have the issues. – demir Oct 26 '19 at 01:07
  • I've also noticed that I've been having issues with the snapping/digitization tools (not snapping at right angle, or snapping with an offset to target) which I've asked about here. Can't tell if related. https://gis.stackexchange.com/questions/339863/qgis-snaps-with-offset-while-using-advanced-digitization – demir Oct 26 '19 at 01:13
  • I wrote my answer there, I can't reproduce the problem with GeoJSON, in geojson.io I can't zoom in enough to perceive the error. – Gabriel De Luca Oct 26 '19 at 04:30
  • Creating the custom coordinate system fixed the perpendicular lines, but export still generates skewed/distorted shapes at room level. – demir Oct 26 '19 at 06:32
  • About the Edit 3: You are just one step away from thinking about topological objects. But I don't know if GeoJSON supports them. For now, you must add the vertices at polygons that have adjacencies. The lack of parallelism on such a small scale does not cease to amaze me, if you do not find it similar in rendering at QGIS on the same scale and the same projective system, I am inclined to think that the application that is rendering your polygons it is the one who produces the inconvenience. – Gabriel De Luca Oct 26 '19 at 16:42
  • @GabrielDeLuca I added a new GeoJSON file in the comments above. You can actually open it in geojson.io and see the distorted angles of rooms that look otherwise parallel in QGIS. – demir Oct 26 '19 at 18:12

3 Answers3

6

ogre.adc4gis.com uses a GDAL utility to do the conversion from shapefile to GeoJSON. QGIS also uses GDAL, which would explain similar results.

The GDAL GeoJSON driver can give two types of GeoJSON, the deprecated version (2008) which allows any CRS to be used, and the official version (RFC7946) which only has one CRS CRS:84 ~ which is WGS:84 with coordinates in Long/lat order (similar but not the same as EPSG:4326).

By default if you create GeoJSON using the GDAL driver to create the deprecated version (GeoJSON 2008) you will get a coordinate precision of 15. If you use the driver to create GeoJSON RFC 7946 you will get a coordinate precision of 7.

As has been mentioned in comments a coordinate precision of 99 is effectively nonsense; are you really measuring to sub-atomic particle level?

See Measuring accuracy of latitude and longitude?

If your building outlines have been measured by laser scanner and you want to keep that precision in the data then a coordinate precision of 9 would be the absolute maximum you'd want.

If you want RFC7946 GeoJSON (to use in Mapbox), and you want a precision higher than 7, I can't see how to change the coordinate precision using ogre.adc4gis.com, it may be possible in QGIS, otherwise you could just use the ogr2ogr tool yourself on the command line.

Something like:

ogr2ogr -f GeoJSON -t_srs crs:84  output.geojson input.shp -lco:RFC7946=YES -lco:COORDINATE_PRECISION=9
nmtoken
  • 13,355
  • 5
  • 38
  • 87
  • Thank you nmtoken for introducing me to the tool. This does not solve my problem however, as the inconsistencies are still there (Edit 1 above) – demir Oct 25 '19 at 21:42
2

As noted in @JakobMiksch's comment:

in general EPSG:3857 should only be used for displaying. Your data should never be in this coordinate reference system. It's better if you create your new layer in EPSG:4326 and then export it to GeoJSON.

Even when rendering with EPSG:3857, I found that II had to create the new shapefile layer with EPSG:4326, which both still rendered fine, allowing me to utilize all the digitization tools, but when exported, it gave me an accurate export.

PolyGeo
  • 65,136
  • 29
  • 109
  • 338
demir
  • 111
  • 4
1

I can't reproduce that behaviour.

In QGIS, rendering the canvas in EPSG:3857, which is the system in which web maps are rendered, the difference produced can only be seen at a scale of 10000:1, throwing a value less than a micron.

1

In geojson.io, the maximum zoom level that allows me to zoom in is 22, in which I can't see the differences.

2

The same in Mapbox.

3

Therefore, I am not sure what your rendering method is, which at first glance seems to be performing some rounding of the coordinates, and allowing a zoom level at which that rounding is appreciable.

Gabriel De Luca
  • 14,289
  • 3
  • 20
  • 51
  • Interesting. I assume you have used the test.geojson. If I import that into mapbox and render with the same basic template you have used, the gaps are clearly visible as here https://postimg.cc/PLmw6Jw5 – demir Oct 28 '19 at 00:15
  • Yes, I have used the file provided in the question. I had no user in Mapbox so I created one, deleted the layers that came by default and loaded the file as it was. I do not know much about the platform, but something must have to cause that behavior. – Gabriel De Luca Oct 28 '19 at 06:59