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.chaga...@gmail.com> : > 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.s...@googlemail.com > > 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 <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 >>> >>> >> >> _______________________________________________ >> 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
