Re: [sumo-user] OSM to OPENDRIVE scaling issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [sumo-user] OSM to OPENDRIVE scaling issues

From: Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx>
Date: Wed, 14 Mar 2018 08:32:42 +0100
Delivered-to: sumo-user@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/sumo-user>
List-help: <mailto:sumo-user-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/sumo-user>, <mailto:sumo-user-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/sumo-user>, <mailto:sumo-user-request@eclipse.org?subject=unsubscribe>

Hello,

if you look at fullrun.net.xml in the gui, you can see that only the lower left corner of the bounding box is determined by a network edge whereas
the upper right corner is empty. The bounding box value is computed based on one edge that extends far to the north and a different edge that extends far to the east. Due to the non-linearity discussed above, your linear boundary comparison fails.

However, each geometry point in the net.xml has the following properties:

- the mapping embedded in the .net.xml (UTM + offset) allows accurate back-and-forth translation between x,y and lon,lat

- the x,y coordinates match those in the .xodr network

You should be fine in mapping geo-coordinates onto both networks.

regards,

Jakob

2018-03-13 11:24 GMT+01:00 sravan kumar chaganti <sravan.chaganti@xxxxxxxxx>:

Hi Jakob,

Thank you so much for clearing the mess. The approach what you mentioned worked for those files.I used the same approach for few other files, The results are not matching. Attached the files for reference, PFA.

1. The .net.xml file's convBoundary="0.00,0.00,4314.87,4287.14" and origBoundary="78.310312,17.347622,78.350594,17.386423" and projParameter="+proj=utm +zone=44 +ellps=WGS84 +datum=WGS84 +units=m +no_defs".
2. The header tag of the .xodr is follows  <header revMajor="1" revMinor="4" name="" version="1.00" date="Tue Mar 13 12:34:47 2018" north="4287.14" south="0.00" east="4314.87" west="0.00"/>
3. I used upper-left to lower right corner approach.

Observations with proj library:
> echo 78.310312 17.386423 | proj +proj=utm +zone=44 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> 214207.29 1924309.43
> echo 78.350594 17.347622 | proj +proj=utm +zone=44 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> 218430.65 1919953.44

xExtent: 218430.65 - 214207.29 = 4223.35.

am I missing any important steps to match the corners?

Thanks,
sk

On Mon, Mar 12, 2018 at 6:08 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
the discrepancy arises because the origBoundary is given with the lower-left and upper-right corner whereas the actual network coordinates run from the upper-left to the lower right corner (coordinate transformations are not linear).

If you convert the correct corners using the proj library you will get the appropriate convBoundary:
> echo 76.587682 17.848470 | proj +proj=utm +zone=43 +ellps=WGS84 +datum=WGS84      +units=m +no_defs
> 668236.75       1974135.55
> echo 76.615430 17.839935 | proj +proj=utm +zone=43 +ellps=WGS84 +datum=WGS84      +units=m +no_defs
> 671185.83       1973216.18

xExtent: 671185.83 - 668236.75 = 2949.08

regards,
Jakob

2018-03-12 8:11 GMT+01:00 sravan kumar chaganti <sravan.chaganti@xxxxxxxxx>:
Hi,
Thanks Jakob for explaining very clearly and Now I taken .net.xml file's  origBoundary values are reference to calculate the XY boundaries. The observations are as follows.
.net.xml file's origBoundary="76.587682,17.839935,76.615430,17.848470" and the equivalent XY boundaries are convBoundary="0.00,0.00,2949.08,919.30".
After my calculations i got the following boundaries in Cartesian coordinate system ( 0.00,0.00,2941.2,944.6420 ), which are not equal to convBoundary.
There is some differences in XY boundaries. can you please suggest me the calculation/formula you are using to match convBoundary values?
Thanks,
sk

On Sat, Mar 10, 2018 at 3:52 AM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
this is not a bug but rather a misunderstanding. When you downloaded a bounding box from OSM the <way> element was not cut into parts but rather retrieved with all its nodes even those outside the bounding box.
The .net.xml covers the full geometry described by the <node> objects in the osm file (you can replace 'node' with 'poi' and load the file into sumo to check this).
The .xodr file is completely in sync with the .net.xml file.

regards,
Jakob

2018-03-08 13:18 GMT+01:00 sravan kumar chaganti <sravan.chaganti@xxxxxxxxx>:
Hi,

What are the options i have to set while converting .osm to .xodr to produce same scaling without enlarging the boundaries.

Thanks,
sk

On Wed, Mar 7, 2018 at 8:40 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
please provide the .net.xml file as well.

2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <sravan.chaganti@xxxxxxxxx>:
Hi Jacob,

following command is used converting from .osm to .xodr
netconvert --osm-files "Straight_Map.osm" --opendrive-output "Straight_Map.xodr"

following command used for converting from .net.xml to .xodr. without any options i thought it will pick defaults from config
netconvert -s "E:\GEO2XY\Straight_Map.net.xml" --opendrive-output "E:\GEO2XY\map.xodr"

The real geographical limits of that location is X=(0,97.52472);Y=(0,47.59625); and the opendrive header is like following
<header revMajor="1" revMinor="4" name="" version="1.00" date="Wed Mar 07 15:08:12 2018" north="919.30" south="0.00" east="2949.08" west="0.00"/>

Thanks,
sk

On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann <namdre.sumo@xxxxxxxxxxxxxx> wrote:
Hello,
please provide the following information:
- netconvert options for generating the networks
- the contents of the <location» element in your .net.xml file
- the contents of the <header> element in your .xodr file
regards,
Jakob

2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <sravan.chaganti@xxxxxxxxx>:
Hi Team,

I exported some patch of OpenStreetMap data as .osm file and converted that file into OPENDRIVE (.xodr) and SUMO(.net.xml) formats using netconvert command.

But unfortunately the inertial boundaries on the opendrive file is big compared to real dimentions of that area while comparing the both the boundaries.

why does the area is scaling up? will you please answer my question?

what does i do if the real geographic boundaries and opendrive boundaries has to match?

Thanks,
sk

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

Follow-Ups:
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti

References:
- [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: Jakob Erdmann
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: Jakob Erdmann
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: Jakob Erdmann
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: Jakob Erdmann
- Re: [sumo-user] OSM to OPENDRIVE scaling issues
  - From: sravan kumar chaganti

Prev by Date: Re: [sumo-user] POI placing
Next by Date: Re: [sumo-user] CentOS 6 installation issue
Previous by thread: Re: [sumo-user] OSM to OPENDRIVE scaling issues
Next by thread: Re: [sumo-user] OSM to OPENDRIVE scaling issues
Index(es):
- Date
- Thread

Breadcrumbs