search

eclipse-sumo / sumo

Eclipse SUMO is an open source, highly portable, microscopic and continuous traffic simulation package designed to handle large networks. It allows for intermodal simulation including pedestrians and comes with a large set of tools for scenario creation.
https://eclipse.dev/sumo
Eclipse Public License 2.0
2.36k stars 1.36k forks source link

Read Data axis to CRS axis mapping #13945

Open michelmadeira opened 8 months ago

michelmadeira commented 8 months ago

Hi, I´m trying to use polyconvert to generate TAZ definition from a shapefile.

The shapefile was generate using EPSG:4326

I´m passing the network as parameter too, so polyconvert calculate de projection and offset parameters.

But it´s not working. The coordinates values are being off the boundarys in the output polygons.xml file. I manage to generate a taz file once, but out of nowhere stopped working. I tried many time with different projections, networks, parameters..

Can someone help me? I´m attaching the files.

atual_rede_tarde.net.zip

m-kro commented 8 months ago

Polyconvert expects to get longitude information from GDAL/Proj calling getX() on a point. It seems longitude is encoded as Y, though...?

m-kro commented 8 months ago

The polygons are loading just fine in QGIS, so there must be some thing we do not catch yet...

m-kro commented 8 months ago

@michelmadeira OK the problem is the following: Your shape file has longitude/latitude values swapped. This seems to be some valid(?) variant as other software like QGIS can deal with it. Do you know more about this question?

We use the GDAL/Proj libraries for everything regarding geographic coordinates and projection and assumed the X coordinate of a point would contain the longitude value. This works well with our other test shapes (and they contain longitude values which are clearly out of range for latitudes).

m-kro commented 8 months ago

@michelmadeira Should work now when rebuilt from Github source.

Read more at GDAL about the "standards" for data / coordinate axis order to understand the underlying problem. Incredible this problem has gone unnoticed for very long.

michelmadeira commented 8 months ago

Hi guys,

Thanks for your help.

I´ll try to swap coordinates in QGIS, then import. Or rebuild, as you suggested.

Here we say "Lat/Long" in conversations. Just because sounds more natural then "Long/Lat." Pretty sure that saw anywhere in QGIS too.

I totally agree with (X,Y) as a standard. No reason to (Y,X). So I start to say "Long/Lat" since now.

Just guessing the origins of the problem.

I think you can try to contact someone in QGIS or GDAL. Thats a simple and serious question.

Glad to contribute.

behrisch commented 8 months ago

@m-kro We should do this in netconvert too and probably also check how this is supposed to interact with the option --shapefile.traditional-axis-mapping

m-kro commented 8 months ago

@behrisch Actually after looking at the code again, I'd vote for making --shapefile.traditional-axis-mapping true obligatory / use it in case there is a coordinate system in the input data. It has no effect on data without projection information (all our tests) and ensures the right axis order for the projected sumo coordinates.