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

[Jakob Erdmann]

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 
:

> 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  * 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  > 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.chaga...@gmail.com>:
>>
>>> 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.s...@googlemail.com> wrote:
>>>
 Hello,
 this is not a bug but rather a misunderstanding. When you downloaded a
 bounding box from OSM the  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  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.chaga...@gmail.com>:

> 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.s...@googlemail.com> wrote:
>
>> please provide the .net.xml file as well.
>>
>> 2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <
>> sravan.chaga...@gmail.com>:
>>
>>> 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 

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

[Jakob Erdmann]

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 :

> 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  > wrote:
>
>> Hello,
>> this is not a bug but rather a misunderstanding. When you downloaded a
>> bounding box from OSM the  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  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.chaga...@gmail.com>:
>>
>>> 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.s...@googlemail.com> wrote:
>>>
 please provide the .net.xml file as well.

 2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <
 sravan.chaga...@gmail.com>:

> 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
> *  west="0.00"/>*
>
> Thanks,
> sk
>
>
> On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann <
> namdre.s...@googlemail.com> wrote:
>
>> Hello,
>> please provide the following information:
>> - netconvert options for generating the networks
>> - the contents of the > - the contents of the  element in your .xodr file
>> regards,
>> Jakob
>>
>> 2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <
>> sravan.chaga...@gmail.com>:
>>
>>> 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@eclipse.org
>>> 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@eclipse.org
>> 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 

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

[sravan kumar chaganti]

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 
wrote:

> Hello,
> this is not a bug but rather a misunderstanding. When you downloaded a
> bounding box from OSM the  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  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.chaga...@gmail.com>:
>
>> 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 > > wrote:
>>
>>> please provide the .net.xml file as well.
>>>
>>> 2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <
>>> sravan.chaga...@gmail.com>:
>>>
 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
 * >>> west="0.00"/>*

 Thanks,
 sk


 On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann <
 namdre.s...@googlemail.com> wrote:

> Hello,
> please provide the following information:
> - netconvert options for generating the networks
> - the contents of the  - the contents of the  element in your .xodr file
> regards,
> Jakob
>
> 2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <
> sravan.chaga...@gmail.com>:
>
>> 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@eclipse.org
>> 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@eclipse.org
> 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@eclipse.org
 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@eclipse.org
>>> 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@eclipse.org
>> 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@eclipse.org
> To change your delivery options, retrieve your password, 

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

[Jakob Erdmann]

Hello,
this is not a bug but rather a misunderstanding. When you downloaded a
bounding box from OSM the  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  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 
:

> 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 
> wrote:
>
>> please provide the .net.xml file as well.
>>
>> 2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <
>> sravan.chaga...@gmail.com>:
>>
>>> 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
>>> * *
>>>
>>> Thanks,
>>> sk
>>>
>>>
>>> On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann <
>>> namdre.s...@googlemail.com> wrote:
>>>
 Hello,
 please provide the following information:
 - netconvert options for generating the networks
 - the contents of the :

> 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@eclipse.org
> 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@eclipse.org
 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@eclipse.org
>>> 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@eclipse.org
>> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

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

[sravan kumar chaganti]

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 
wrote:

> please provide the .net.xml file as well.
>
> 2018-03-07 12:44 GMT+01:00 sravan kumar chaganti <
> sravan.chaga...@gmail.com>:
>
>> 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
>> * *
>>
>> Thanks,
>> sk
>>
>>
>> On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann > > wrote:
>>
>>> Hello,
>>> please provide the following information:
>>> - netconvert options for generating the networks
>>> - the contents of the >> - the contents of the  element in your .xodr file
>>> regards,
>>> Jakob
>>>
>>> 2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <
>>> sravan.chaga...@gmail.com>:
>>>
 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@eclipse.org
 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@eclipse.org
>>> 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@eclipse.org
>> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

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

[Jakob Erdmann]

please provide the .net.xml file as well.

2018-03-07 12:44 GMT+01:00 sravan kumar chaganti 
:

> 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
> * *
>
> Thanks,
> sk
>
>
> On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann 
> wrote:
>
>> Hello,
>> please provide the following information:
>> - netconvert options for generating the networks
>> - the contents of the > - the contents of the  element in your .xodr file
>> regards,
>> Jakob
>>
>> 2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <
>> sravan.chaga...@gmail.com>:
>>
>>> 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@eclipse.org
>>> 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@eclipse.org
>> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

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

[sravan kumar chaganti]

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
* *

Thanks,
sk


On Wed, Mar 7, 2018 at 4:54 PM, Jakob Erdmann 
wrote:

> Hello,
> please provide the following information:
> - netconvert options for generating the networks
> - the contents of the  - the contents of the  element in your .xodr file
> regards,
> Jakob
>
> 2018-03-07 12:03 GMT+01:00 sravan kumar chaganti <
> sravan.chaga...@gmail.com>:
>
>> 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@eclipse.org
>> 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@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/sumo-user
>
>


Straight_Map.osm
Description: Binary data


Straight_Map.xodr
Description: Binary data
___
sumo-user mailing list
sumo-user@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user

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

[Jakob Erdmann]

Hello,
please provide the following information:
- netconvert options for generating the networks
- the contents of the 
:

> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-user