[sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)

[Deaver, Dawne CIV USA AMC]

Classification: UNCLASSIFIED
Caveats: NONE



Could someone help me understand the coordinate system in an imported
OSM road network? I understand OSM is in WGS84 coordinates. I want to
import the OSM road network into a projected coordinate system in UTM
zone 18 (Virginia, USA). Below is the header and first few lines of my
imported network.



Is my interpretation of these parameters correct?

"netOffset" = the x,y offset in meters from the SUMO network origin to
the UTM zone origin

"convBoundary" = the x,y coordinates in meters of the Lower Left and
Upper Right corners of the imported network

"origBoundary" = the LAT,LON coordinates of the source data, in this
case, in WGS84



My issue is that when I use an off-line coordinate system converter (or
use PROJ.4 directly) to convert the netOffset in UTM to WGS84, this does
not result in the LAT,LON of the original boundary as I expected. In
fact, the result is close, but it about 200m off.



Am I misinterpreting something?



Thanks, in advance,

-Dawne Deaver







<!-- generated on 01/08/10 17:13:13 by SUMO netconvert Version 0.11.0

<configuration>



<input

xml-type-files="osm_input_types.typ.xml"

osm-files="temp.osm"

/>



<output

output-file="osm_rich_PROJ.net.xml"

/>



<projection

use-projection="true"

proj="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"

/>



<edge_removal

remove-edges.by-vclass="rail_slow,rail_fast,bicycle,pedestrian"

/>



<processing

no-turnarounds="true"

/>



</configuration>

-->



<net>



<location netOffset="-278475.06,-4147423.25"
convBoundary="0.00,0.00,9985.78,17099.00"
origBoundary="-77.507133,37.448849,-77.393898,37.602371"
projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>



Classification: UNCLASSIFIED
Caveats: NONE

[Michael Behrisch]

Hi,

Post by Deaver, Dawne CIV USA AMC
Is my interpretation of these parameters correct?
"netOffset" = the x,y offset in meters from the SUMO network origin to
the UTM zone origin
"convBoundary" = the x,y coordinates in meters of the Lower Left and
Upper Right corners of the imported network
"origBoundary" = the LAT,LON coordinates of the source data, in this
case, in WGS84

Yes, your interpretation is correct.

Post by Deaver, Dawne CIV USA AMC
My issue is that when I use an off-line coordinate system converter (or
use PROJ.4 directly) to convert the netOffset in UTM to WGS84, this does
not result in the LAT,LON of the original boundary as I expected. In
fact, the result is close, but it about 200m off.

I think it is a valid result, the point is just that the bounding box on an
ellipsoid (I don't know whether this is a well defined term at all) is
different from the bounding box in the plane. We just take the minimum
and maximum longitude and latitude separately, this is only very
seldom a point in the net and therefore is probably never projected.
Thus the minimum (and maximum) may be different after projection.

Further deviations stem from the fact that sumo calculates with
single precision only, while (the command line) proj uses
double precision. This is subject to change in the next sumo release.

May I ask what you are trying to simulate?

Regards,
Michael

[Deaver, Dawne CIV USA AMC]

Classification: UNCLASSIFIED
Caveats: NONE



Michael, thanks for your reply.



1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
image). I had assumed I could simply apply this offset:



RouteX_UTM = RouteX - netOffsetX

RouteY_UTM = RouteY - netOffsetY



Does that process seem to you like it should work?





2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
nor decimal degrees. For example, from my vtypeprobe output is:



<vehicle-type-probes>

<timestep time="0" id="0" vtype="">

<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>

<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>

<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>

</timestep>



Those are not valid values in arcseconds. Here I am converting from
Deg/Min/Sec format to arcseconds by the following convention:

Arcseconds = (D*3600) + (M*60) + S



This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
boundaries should be:



<location netOffset="-278475.06,-4147423.25"

convBoundary="0.00,0.00,9985.78,17099.00"

origBoundary="-77.507133,37.448849,-77.393898,37.602371"

projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>





Again, thanks for any advice or insights you can provide.

-Dawne



Classification: UNCLASSIFIED
Caveats: NONE

[Deaver, Dawne CIV USA AMC]

Classification: UNCLASSIFIED
Caveats: NONE

I got the answer to my question #2 below. This wiki page could be
updated to correct the units listed for lat/lon in the vtypeprobe output
file, which are not arcseconds as indicated. In the source code, the
units in degrees are multiplied by a factor of 100,000 and this is the
value output in vtypeprobe.

https://sourceforge.net/apps/mediawiki/sumo/index.php?title=SUMO_OUTPUT_
VTYPEPROBE

Thanks,
-Dawne

-----Original Message-----
From: Deaver, Dawne CIV USA AMC
Sent: Monday, January 11, 2010 2:19 PM
To: 'sumo-***@lists.sourceforge.net'
Subject: Understanding Coordinates and Projections in imported OSM
network (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE



Michael, thanks for your reply.



1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
image). I had assumed I could simply apply this offset:



RouteX_UTM = RouteX - netOffsetX

RouteY_UTM = RouteY - netOffsetY



Does that process seem to you like it should work?





2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
nor decimal degrees. For example, from my vtypeprobe output is:



<vehicle-type-probes>

<timestep time="0" id="0" vtype="">

<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>

<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>

<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>

</timestep>



Those are not valid values in arcseconds. Here I am converting from
Deg/Min/Sec format to arcseconds by the following convention:

Arcseconds = (D*3600) + (M*60) + S



This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
boundaries should be:



<location netOffset="-278475.06,-4147423.25"

convBoundary="0.00,0.00,9985.78,17099.00"

origBoundary="-77.507133,37.448849,-77.393898,37.602371"

projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>





Again, thanks for any advice or insights you can provide.

-Dawne



Classification: UNCLASSIFIED
Caveats: NONE


Classification: UNCLASSIFIED
Caveats: NONE

[Daniel Krajzewicz]

Dear Dawne,

-----Ursprüngliche Nachricht-----
Gesendet: 11.01.10 20:22:44
Betreff: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Michael, thanks for your reply.
1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
RouteX_UTM = RouteX - netOffsetX
RouteY_UTM = RouteY - netOffsetY
Does that process seem to you like it should work?

During import, the network is at first projected to cartesian coordinates, first. Then, it is moved so that its origin is at (0,0).

This means, for getting back your UTM-coordinates, you have to subtract the network offset first, as you wrote. Then, you have to apply an inverse transformation of the initial projection.

proj has a function named pj_inv. It has to be initialised with the original projection parameters which are also stored in the network file as you already know. I hope this works, and in principle it should return valid coordinates - if neglecting floating point errors.

In fact, this is also used in GUISIM for displaying the coordinates in the bar located in the right bottom of the window which shows where the cursor position is. The code is in void GeoConvHelper::cartesian2geo(Position2D &cartesian) in src/utils/common/GeoConvHelper.cpp.

Well, it should work, but it would be nice if you could report whether the offset of 200m you reported in another mail still occurs. I also added a this description to the wiki (http://sourceforge.net/apps/mediawiki/sumo/index.php?title=SUMO_Road_Networks#Coordinates_and_alignment). It would be nice if someone coule revisit it - any help is appreciated.


sincerely,
Daniel

2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
<vehicle-type-probes>
<timestep time="0" id="0" vtype="">
<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>
<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>
<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>
</timestep>
Those are not valid values in arcseconds. Here I am converting from
Arcseconds = (D*3600) + (M*60) + S
This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
<location netOffset="-278475.06,-4147423.25"
convBoundary="0.00,0.00,9985.78,17099.00"
origBoundary="-77.507133,37.448849,-77.393898,37.602371"
projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>
Again, thanks for any advice or insights you can provide.
-Dawne
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
sumo-user mailing list
https://lists.sourceforge.net/lists/listinfo/sumo-user

____________________________________________________________________
WEB.DE MillionenKlick: Kostenlos tippen, täglich 1 Million gewinnen!
http://produkte.web.de/go/07/

[Deaver, Dawne CIV USA AMC]

Classification: UNCLASSIFIED
Caveats: NONE

Daniel,

I have independently checked the coordinates of a single junction point in my imported OSM network with source data that I am viewing in ArcView and was able to match the data (in UTM coordinates) to within 1.2 meters. This is well within the error of my method (ie, ability to point the mouse to my point of interest).

My confusion arose from the bounding box. Here I assumed that the corners of the original bounding box (given in lat/lon) should correspond to the corners of the converted bounding box (given in local Cartesian coordinates). When I performed the conversion between the two sets of coordinates, I found a ~200m difference in the location of the corners. I believe I understand now that these corners do not actually correspond to the same point in space because after the projection is performed a new bounding box is defined.

Again, thanks for your assistance and clarifications.
-Dawne

-----Original Message-----
From: Daniel Krajzewicz [mailto:***@web.de]
Sent: Tuesday, January 12, 2010 10:31 AM
To: Deaver, Dawne CIV USA AMC; sumo-***@lists.sourceforge.net
Subject: Re: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)

Dear Dawne,

-----Ursprüngliche Nachricht-----
Gesendet: 11.01.10 20:22:44
Betreff: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Michael, thanks for your reply.
1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
RouteX_UTM = RouteX - netOffsetX
RouteY_UTM = RouteY - netOffsetY
Does that process seem to you like it should work?

During import, the network is at first projected to cartesian coordinates, first. Then, it is moved so that its origin is at (0,0).

This means, for getting back your UTM-coordinates, you have to subtract the network offset first, as you wrote. Then, you have to apply an inverse transformation of the initial projection.

proj has a function named pj_inv. It has to be initialised with the original projection parameters which are also stored in the network file as you already know. I hope this works, and in principle it should return valid coordinates - if neglecting floating point errors.

In fact, this is also used in GUISIM for displaying the coordinates in the bar located in the right bottom of the window which shows where the cursor position is. The code is in void GeoConvHelper::cartesian2geo(Position2D &cartesian) in src/utils/common/GeoConvHelper.cpp.

Well, it should work, but it would be nice if you could report whether the offset of 200m you reported in another mail still occurs. I also added a this description to the wiki (http://sourceforge.net/apps/mediawiki/sumo/index.php?title=SUMO_Road_Networks#Coordinates_and_alignment). It would be nice if someone coule revisit it - any help is appreciated.


sincerely,
Daniel

2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
<vehicle-type-probes>
<timestep time="0" id="0" vtype="">
<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>
<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>
<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>
</timestep>
Those are not valid values in arcseconds. Here I am converting from
Arcseconds = (D*3600) + (M*60) + S
This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
<location netOffset="-278475.06,-4147423.25"
convBoundary="0.00,0.00,9985.78,17099.00"
origBoundary="-77.507133,37.448849,-77.393898,37.602371"
projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>
Again, thanks for any advice or insights you can provide.
-Dawne
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
sumo-user mailing list
https://lists.sourceforge.net/lists/listinfo/sumo-user

____________________________________________________________________
WEB.DE MillionenKlick: Kostenlos tippen, täglich 1 Million gewinnen!
http://produkte.web.de/go/07/

Classification: UNCLASSIFIED
Caveats: NONE

[Daniel Krajzewicz]

Dear Dawne,

Thank you very much for this report. Actually, for me, this seems not to be a wrong description, but even more a bug yielding from somehow new geo-coordinates processing. I'll open a ticket on this.

sincerely,
Daniel

-----Ursprüngliche Nachricht-----
Gesendet: 11.01.10 22:12:23
Betreff: Re: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
I got the answer to my question #2 below. This wiki page could be
updated to correct the units listed for lat/lon in the vtypeprobe output
file, which are not arcseconds as indicated. In the source code, the
units in degrees are multiplied by a factor of 100,000 and this is the
value output in vtypeprobe.
https://sourceforge.net/apps/mediawiki/sumo/index.php?title=SUMO_OUTPUT_
VTYPEPROBE
Thanks,
-Dawne
-----Original Message-----
From: Deaver, Dawne CIV USA AMC
Sent: Monday, January 11, 2010 2:19 PM
Subject: Understanding Coordinates and Projections in imported OSM
network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Michael, thanks for your reply.
1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
RouteX_UTM = RouteX - netOffsetX
RouteY_UTM = RouteY - netOffsetY
Does that process seem to you like it should work?
2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
<vehicle-type-probes>
<timestep time="0" id="0" vtype="">
<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>
<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>
<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>
</timestep>
Those are not valid values in arcseconds. Here I am converting from
Arcseconds = (D*3600) + (M*60) + S
This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
<location netOffset="-278475.06,-4147423.25"
convBoundary="0.00,0.00,9985.78,17099.00"
origBoundary="-77.507133,37.448849,-77.393898,37.602371"
projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>
Again, thanks for any advice or insights you can provide.
-Dawne
Classification: UNCLASSIFIED
Caveats: NONE
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
sumo-user mailing list
https://lists.sourceforge.net/lists/listinfo/sumo-user

________________________________________________________________________
Kostenlos tippen, täglich 1 Million gewinnen: zum WEB.DE MillionenKlick!
http://produkte.web.de/go/08/

[Daniel Krajzewicz]

Hello Dawne,

yes, this should be right. I think that's also what Michael wrote.

As you are working with OSM networks: it would be nice to share some experience. We rather use commercial networks internally, but are quite interested in OSM networks due to their applicability for free scenarios. So if you recognize an issue, please report.

sincerely,
Daniel

-----Ursprüngliche Nachricht-----
Gesendet: 13.01.10 21:11:41
Betreff: RE: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Daniel,
I have independently checked the coordinates of a single junction point in my imported OSM network with source data that I am viewing in ArcView and was able to match the data (in UTM coordinates) to within 1.2 meters. This is well within the error of my method (ie, ability to point the mouse to my point of interest).
My confusion arose from the bounding box. Here I assumed that the corners of the original bounding box (given in lat/lon) should correspond to the corners of the converted bounding box (given in local Cartesian coordinates). When I performed the conversion between the two sets of coordinates, I found a ~200m difference in the location of the corners. I believe I understand now that these corners do not actually correspond to the same point in space because after the projection is performed a new bounding box is defined.
Again, thanks for your assistance and clarifications.
-Dawne
-----Original Message-----
Sent: Tuesday, January 12, 2010 10:31 AM
Subject: Re: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Dear Dawne,

-----Ursprüngliche Nachricht-----
Gesendet: 11.01.10 20:22:44
Betreff: [sumo-user] Understanding Coordinates and Projections in imported OSM network (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Michael, thanks for your reply.
1. I am using SUMO to define the vehicle routes that I intend to
import into a 3-D simulation, so it is important for me to match up the
route coordinates with the other data (aerial imagery) that I am working
with. I can project my other data into UTM, but I am trying to figure
out what offset to apply to the route X,Y position to get it to match up
to the X,Y position in UTM (and hence, to overlay on the roads in my
RouteX_UTM = RouteX - netOffsetX
RouteY_UTM = RouteY - netOffsetY
Does that process seem to you like it should work?

During import, the network is at first projected to cartesian coordinates, first. Then, it is moved so that its origin is at (0,0).
This means, for getting back your UTM-coordinates, you have to subtract the network offset first, as you wrote. Then, you have to apply an inverse transformation of the initial projection.
proj has a function named pj_inv. It has to be initialised with the original projection parameters which are also stored in the network file as you already know. I hope this works, and in principle it should return valid coordinates - if neglecting floating point errors.
In fact, this is also used in GUISIM for displaying the coordinates in the bar located in the right bottom of the window which shows where the cursor position is. The code is in void GeoConvHelper::cartesian2geo(Position2D &cartesian) in src/utils/common/GeoConvHelper.cpp.
Well, it should work, but it would be nice if you could report whether the offset of 200m you reported in another mail still occurs. I also added a this description to the wiki (http://sourceforge.net/apps/mediawiki/sumo/index.php?title=SUMO_Road_Networks#Coordinates_and_alignment). It would be nice if someone coule revisit it - any help is appreciated.
sincerely,
Daniel

2. I have a related question, if you don't mind. I read in the
documentation that the values that are reported in the vtypeprobe output
for lat/lon should be in arcseconds. However, the values in my output
file look as if they are in some other unit that is neither arcseconds
<vehicle-type-probes>
<timestep time="0" id="0" vtype="">
<vehicle id="Rand0" lane="-6038431#2_0" pos="0.00"
x="6337.68" y="8204.26" lat="3752254.10" lon="-7743505.10"
speed="0.00"/>
<vehicle id="Rand1" lane="-6040380#1_0" pos="0.00"
x="6644.34" y="9354.51" lat="3753297.42" lon="-7743192.29"
speed="0.00"/>
<vehicle id="Rand2" lane="37961358#3_0" pos="0.00"
x="5118.76" y="9780.81" lat="3753645.71" lon="-7744930.27"
speed="0.00"/>
</timestep>
Those are not valid values in arcseconds. Here I am converting from
Arcseconds = (D*3600) + (M*60) + S
This area is in Virginia so values around 37d30m N and 77d25m W are in
the right ballpark. A snippet of the imported network shows what the
<location netOffset="-278475.06,-4147423.25"
convBoundary="0.00,0.00,9985.78,17099.00"
origBoundary="-77.507133,37.448849,-77.393898,37.602371"
projParameter="+proj=utm +zone=18 +datum=WGS84 +ellps=WGS84 +units=m"/>
Again, thanks for any advice or insights you can provide.
-Dawne
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
sumo-user mailing list
https://lists.sourceforge.net/lists/listinfo/sumo-user

____________________________________________________________________
WEB.DE MillionenKlick: Kostenlos tippen, täglich 1 Million gewinnen!
http://produkte.web.de/go/07/
Classification: UNCLASSIFIED
Caveats: NONE

________________________________________________________________________
Kostenlos tippen, täglich 1 Million gewinnen: zum WEB.DE MillionenKlick!
http://produkte.web.de/go/08/