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 <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.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
>>>> * <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.s...@googlemail.com> 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.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, 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

Reply via email to