Re: [Talk-us] Rail westerly

2014-12-31 Thread Michael Patrick
 this is where we need rail fans or rail professionals to correct us
where we are wrong, as the structure of the network is what we are defining
with these tags (main and branch),

Oak Ridge National Laboratory: ... Railroad Network is a representation of
the North American railroad system that contains every railroad route in
the US, Canada, and Mexico that has been active since 1993. It is intended
for logical network programming, traffic analyses, and mapping
applications. Corporate structure, a key to the simulation of routing, is
explicitly temporal, allowing historical studies and comparisons.
Supporting data on interlines and corporate ancestry allow the construction
of routable networks for a specific target date. The network is an
extension of the Federal Railroad Administration's strategic network.

Michael Patrick
Geospatial Analyst
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Rail westerly

2014-12-31 Thread stevea

Michael Patrick writes:
(about the Oak Ridge National Laboratory: ... Railroad Network data).

I found these at:

http://www-cta.ornl.gov/transnet/RailRoads.html

And have downloaded (~10 megabytes) a zipped shapefile of the entire 
network (as well as the simplified 7 megabyte one which omits 
inactive lines and contains only current operators, but incorporates 
interlines as network links.)


I knew there had to be something like this in the public domain, and 
I say thank you very much, Michael.


I examine these in JOSM right now.  First they need to be unzipped, 
and it looks like the (provided on that web page) PRJ file to change 
from WGS 84 (default) to either NAD 27 or 83 projection is required. 
I haven't done that to these data in the instant case, but I've 
fiddled these before and I think it is doable.


Results in JOSM (after many seconds of load time) -- and JOSM MUST 
have the Shapefile plug-in -- do indeed display a nationwide network 
of rail lines.  A sample one I chose (UP's Coast line in California, 
which I believe I have gotten mostly correct in OSM recently) has 30 
rather cryptic (at first blush) tags, but these indeed look to be 
usable data.  Geographically, yes, the rail line looks about 
correct though the tag structure will have to be seriously 
harmonized to become something to import into OSM.


This starts to move (quickly) into the direction of a major import 
(and all its required vetting, etc.) into OSM.


I ask others to help me determine the suitability of whether we might 
want to use these data.  I imagine a fair bit of work would be 
required to harmonize the 30 tags into those we might deem 
appropriate for USA rail in OSM, as well as strategies for conflating 
them with existing TIGER rail data.  It's a big, big, BIG job.  On 
the other hand, I could see small segments in these data that 
interest local mappers being used to confirm names or actual track 
locations for existing data on a line-by-line basis, too.


Thanks for really good discussion about this, Charlotte stepping up 
to make a wiki page, Michael's reference to these data and the great 
volunteer, cooperative and collaborative spirits we find in OSM here 
in the USA.


SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Rail westerly

2014-12-31 Thread Charlotte Wolter

Steve,

Thanks to Michael for a great find and to you for trying to make it
usable in OSM. It will be interesting to see what comes out of it.
Sounds like we should hold off on any wiki work for a while. There
is much data to examine, and I'm already doing stuff for HOT.
I'd like to take a look at the materials for Arizona just to 
see if their

names for lines correspond to what I'm seeing already from TIGER.
Like I said before, we have time to make sure we're doing this right.

Charlotte


At 11:24 AM 12/31/2014, you wrote:
Michael Patrick writes: (about the Oak Ridge National Laboratory: 
... Railroad Network data).

I found these at:
http://www-cta.ornl.gov/transnet/RailRoads.html
And have downloaded (~10 megabytes) a zipped shapefile of the entire network
(as well as the simplified 7 megabyte one which omits inactive 
lines and contains

only current operators, but incorporates interlines as network links.)
I knew there had to be something like this in the public domain, and 
I say thank

you very much,

Michael.


I'll examine these in JOSM right now.  First they need to be 
unzipped, and it looks
like the (provided on that web page) PRJ file to change from WGS 84 
(default) to
either NAD 27 or 83 projection is required. I haven't done that to 
these data in the

instant case, but I've fiddled these before and I think it is doable.
Results in JOSM (after many seconds of load time) -- and JOSM MUST have the
Shapefile plug-in -- do indeed display a nationwide network of rail 
lines.  As a sample
I chose (UP's Coast line in California, which I believe I have 
gotten mostly correct
in OSM recently) has 30 rather cryptic (at first blush) tags, but 
these indeed look to
be usable data.  Geographically, yes, the rail line looks about 
correct though the tag
structure seriously will have to be harmonized to become something 
to import into OSM.
This starts to move (quickly) into the direction of a major import 
(and all its required
vetting, etc.) into OSM. I ask others to help me determine the 
suitability of whether we
might want to use these data.  I imagine a fair bit of work would be 
required to
harmonize the 30 tags into those we might deem appropriate for USA 
rail in OSM, as well
as strategies for conflating them with existing TIGER rail 
data.  It's a big, big, BIG job.
On the other hand, I could see small segments in these data that 
interest local mappers
being used to confirm names or actual track locations for existing 
data on a line-by-line

basis, too.
Thanks for really good discussion about this, Charlotte stepping up 
to make a wiki page,
Michael's reference to these data and the great volunteer, 
cooperative and collaborative

spirits we find in OSM here in the USA.

SteveA
California
___
Talk-us mailing list 
mailto:Talk-us@openstreetmap.orgTalk-us@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-us




Charlotte Wolter
927 18th Street Suite A
Santa Monica, California
90403
+1-310-597-4040
techl...@techlady.com
Skype: thetechlady



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [Imports-us] Rail westerly

2014-12-31 Thread Clifford Snow
On Wed, Dec 31, 2014 at 11:24 AM, stevea stevea...@softworkers.com wrote:

 I examine these in JOSM right now.  First they need to be unzipped, and it
 looks like the (provided on that web page) PRJ file to change from WGS 84
 (default) to either NAD 27 or 83 projection is required. I haven't done
 that to these data in the instant case, but I've fiddled these before and I
 think it is doable.


Michael,
Thanks for the info!  You always can be counted on to find data, even if it
is obscure.

SteveA,
I'd be happy to convert the shapefile to an .osm file for importing. It
could be broken into smaller chunks to use the tasking manager. Maybe by
county. Someone needs to create a import page on the wiki and announce it
on the import mailing list.

Let me know what you think.

Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [Imports-us] Rail westerly

2014-12-31 Thread Natfoot
Also good data can be retrieved from time tables, division maps, and track
diagrams.

Nathan Proudfoot
Tel: (425) 835-3638
email: n.pf...@gmail.com

On Wed, Dec 31, 2014 at 12:36 PM, Clifford Snow cliff...@snowandsnow.us
wrote:


 On Wed, Dec 31, 2014 at 11:24 AM, stevea stevea...@softworkers.com
 wrote:

 I examine these in JOSM right now.  First they need to be unzipped, and
 it looks like the (provided on that web page) PRJ file to change from WGS
 84 (default) to either NAD 27 or 83 projection is required. I haven't done
 that to these data in the instant case, but I've fiddled these before and I
 think it is doable.


 Michael,
 Thanks for the info!  You always can be counted on to find data, even if
 it is obscure.

 SteveA,
 I'd be happy to convert the shapefile to an .osm file for importing. It
 could be broken into smaller chunks to use the tasking manager. Maybe by
 county. Someone needs to create a import page on the wiki and announce it
 on the import mailing list.

 Let me know what you think.

 Clifford


 --
 @osm_seattle
 osm_seattle.snowandsnow.us
 OpenStreetMap: Maps with a human touch

 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[Talk-us] Rail USA

2014-12-31 Thread stevea
Also good data can be retrieved from time tables, division maps, and 
track diagrams.


That is true, thank you Nathan Proudfoot.  For the Union Pacific, I 
was disappointed that their web site requires a (UP employee?) login 
and password to gain access to their geographic rail data.  BNSF 
seems a bit better (providing high level rail maps at a nationwide 
glance), and other railroads are probably somewhere around you get 
what you get, but please do take Nathan's good advice and seek data 
directly from a rail entity as a good first strategy for obtaining 
track/lead/line/subdivision names, for example.


I'd be happy to convert the shapefile to an .osm file for importing. 
It could be broken into smaller chunks to use the tasking manager. 
Maybe by county. Someone needs to create a import page on the wiki 
and announce it on the import mailing list.


Thanks, Clifford.  I want to make it clear that it is very early 
first blush that we (OSM) examine these Oak Ridge rail data as a 
POTENTIAL import into OSM.  We are still in the beginning evaluation 
phase of examining the data, and no decision has been reached as to 
whether we will or will not formally import them.  I do cross-post to 
the import-us list as a preliminary heads-up that at least some 
folks in OSM are considering this.  But we are a ways away from 
beginning a formal import process until we (I, others, please share 
your feedback) examine the suitability of these data and begin to 
formulate strategies about how they may best be used/imported.  Or if 
indeed they or a subset of them DO get imported.


Conversion from zipped shapefile to .osm is fairly straightforward: 
simply unzip, fiddle the geospatial coordinate system to be proper 
(I'm still working on this), open in JOSM with the Shapefile plug-in 
enabled, and there you go.  Saving to .osm is straightforward after 
that, but right about here in the workflow is where it might make 
sense to break up data (say, state-by-state).


As for a tasking manager breaking up the data, yes, perhaps a 
state-by-state approach is a good first whack at this.  49 (Alaska 
data are included, Hawaii, no) is a manageable number of 
sub-projects but around 3000 at a county level, whew, not so 
helpful.  But before we do that, I think I'd like (us, me, others...) 
to take a look at those 30 or so tags on each line and see if we 
can begin to make sense of them and how they might turn into useful 
OSM data.  I believe that's an important sub-task to start to do 
first.  Some sort of a table lookup from the abbreviations used in 
those tags to something that is more human-readable is going to be 
required, I can determine that already.


BTW, the actual track data might actually be better expressed by 
OSM's existing TIGER import of rail data.  (And I think that is a 
GOOD thing, as would remove the requirement for conflation of the 
two).  The Oak Ridge track data, while there seem a bit sketchy in 
comparison to OSM's TIGER rail.  Jury still out, evaluation of Oak 
Ridge data continues.


We could use that wiki to have these conversations, but Charlotte 
(while she did volunteer to begin it) has a full plate now.  Perhaps 
someone else could plant the initial seed for a USA Rail 
WikiProject?  If you wish to do so, contact me or Charlotte for a 
Draft 3 that Charlotte, Alexander and I evolved in the last few 
days.


SteveA
California___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Rail westerly

2014-12-31 Thread Darrell Fuhriman
Yes, WGS84 because that’s what’s used by GPS (which was, after all, the 
original data source for OSM). 

Of course, then there’s the question of *which* WGS84 definition we’re talking 
about. You actually can’t assumed that current definitions of WGS84 and NAD83 
are 1m difference.  You can dip your toe into the complexity here: 
http://www.ngs.noaa.gov/CORS/Articles/WGS84NAD83.pdf

Also note, that the satellite photography used for a great deal of OSM mapping 
has much less than 1m accuracy, and as you note, unless you’re using expensive 
GPS, you’re not likely to get 1m accuracy anyway.

Relatedly, I’m curious if anyone has used one of these guys: 
http://gps.dualav.com/explore-by-lifestyle/outdoors/

d.

On Dec 31, 2014, at 13:56, Dave Mansfield mansfie...@chartermi.net wrote:

 
 That brings up a good question. What datum is used by OSM? I would assume 
 it's WGS 84. NAD 83 is within about a meter of WGS 84. That’s closer than the 
 GPS units most of us have so would not cause much of an error if any. NAD 27 
 on the other hand could be off by as much as 180 meters.
 
 Dave
 
 -Original Message-
 From: stevea [mailto:stevea...@softworkers.com] 
 Sent: Wednesday, December 31, 2014 2:24 PM
 To: talk-us@openstreetmap.org
 Cc: imports...@openstreetmap.org
 Subject: Re: [Talk-us] Rail westerly
 
 I examine these in JOSM right now.  First they need to be unzipped, and it 
 looks like the (provided on that web page) PRJ file to change from WGS 84 
 (default) to either NAD 27 or 83 projection is required. 
 I haven't done that to these data in the instant case, but I've fiddled these 
 before and I think it is doable.
 
 SteveA
 California
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us
 
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[Talk-us] NAD 27 data to OSM's native WGS 84 data

2014-12-31 Thread stevea

I wrote:
I examine these in JOSM right now.  First they need to be unzipped, 
and it looks like the (provided on that web page) PRJ file to change 
from WGS 84 (default) to either NAD 27 or 83 projection is required.
I haven't done that to these data in the instant case, but I've 
fiddled these before and I think it is doable.


OSM uses WGS-84 as its default, and I erred in not realizing these 
data are in NAD 27, so a conversion does seem to be necessary.  When 
you open them as-is with JOSM (+ Shapefile plug-in), you get an alert:


Unable to detect Coordinate Reference System.  Would you like to 
fallback to ESPG:4326 (WGS 84)?


This implies that a fix string (perhaps via a .prj file, see below) 
is required to get JOSM to convert (or re-project) from the 
native NAD 27 to WGS 84.  This is truly required, I believe.


Dave Mansfield writes:
That brings up a good question. What datum is used by OSM? I would 
assume it's WGS 84. NAD 83 is within about a meter of WGS 84. That's 
closer than the GPS units most of us have so would not cause much of 
an error if any. NAD 27 on the other hand could be off by as much as 
180 meters.


The Oak Ridge Page http://www-cta.ornl.gov/transnet/RailRoads.html 
does say this:


Geographic accuracy is roughly equivalent to a scale of 1:100,000, 
but is object-specific (see documentation). Comparison to a set of 
70,000 FRA inspection car GPS locations showed a lateral offset of 20 
m root mean square, so a reasonable estimate of the geographic 
accuracy of active lines in CONUS would be 25 m RMS. The geographic 
coordinate system is decimal degrees, datum NAD27. No ESRI PRJ file 
is included with the shapefiles, but if there were, it would look 
like this (cut and paste if needed):


GEOGCS[GCS_North_American_1927,DATUM[D_North_American_1927,SPHEROID[Clarke_1866,6378206.4,294.9786982]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]]

Any magic incantation that will just do this (for shapefile data) 
is appreciated.  I don't know if copy-pasting the above string into a 
.prj in the shapefile folder will direct JOSM (via Shapefile plug-in) 
to adjust the data to WGS 84, or if something different is 
required.  It is even possible that clicking on JOSM's alert button 
of Yes is all that is required, but I'm not sure.  Thank you in 
advance.


SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] NAD 27 data to OSM's native WGS 84 data

2014-12-31 Thread Darrell Fuhriman

 
 Any magic incantation that will just do this (for shapefile data) is 
 appreciated.  I don't know if copy-pasting the above string into a .prj in 
 the shapefile folder will direct JOSM (via Shapefile plug-in) to adjust the 
 data to WGS 84, or if something different is required.  It is even possible 
 that clicking on JOSM's alert button of Yes is all that is required, but 
 I'm not sure.  Thank you in advance.
 

Well, just clicking “Yes” will definitely not work, since JOSM won’t know what 
to convert from.

I don’t know if JOSM doesn’t reprojection. But if you want to just do it before 
loading the data into JOSM and you have OGR/GDAL installed:

ogr2ogr -s_srs EPSG:4267 -t_srs EPSG:4326  output.shp input.shp


d.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] NAD 27 data to OSM's native WGS 84 data

2014-12-31 Thread stevea
Any magic incantation that will just do this (for shapefile 
data) is appreciated.  I don't know if copy-pasting the above 
string into a .prj in the shapefile folder will direct JOSM (via 
Shapefile plug-in) to adjust the data to WGS 84, or if something 
different is required.  It is even possible that clicking on JOSM's 
alert button of Yes is all that is required, but I'm not sure. 
Thank you in advance.


Well, just clicking Yes will definitely not work, since JOSM won't 
know what to convert from.


I don't know if JOSM doesn't reprojection. But if you want to just 
do it before loading the data into JOSM and you have OGR/GDAL 
installed:


ogr2ogr -s_srs EPSG:4267 -t_srs EPSG:4326  output.shp input.shp


I do have OGR/GDAL installed (for this and other reasons!) and have 
done exactly this before (for example, during my US Forest Service 
data harmonization in Region 5/California a couple years ago).  Thank 
you, Darrell, for confirming this.


To be clear to anybody else who wishes to use the Oak Ridge Rail 
data, a re-projection from NAD 27to WGS 84 absolutely IS required, 
and one way to do that is to use the ogr2ogr command above.  For 
those new to this, the quickest way is to install GDAL appropriate to 
your operating system.


Thanks for the quick response!

SteveA
California___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] NAD 27 data to OSM's native WGS 84 data

2014-12-31 Thread Paul Norman


On 12/31/2014 2:14 PM, stevea wrote:
OSM uses WGS-84 as its default, and I erred in not realizing these 
data are in NAD 27, so a conversion does seem to be necessary.

Not just by default - OSM is defined as only being in WGS84.

When you open them as-is with JOSM (+ Shapefile plug-in), you get an 
alert:


Unable to detect Coordinate Reference System.  Would you like to 
fallback to ESPG:4326 (WGS 84)?


This implies that a fix string (perhaps via a .prj file, see below) 
is required to get JOSM to convert (or re-project) from the native 
NAD 27 to WGS 84.  This is truly required, I believe.
To properly convert from NAD27 to WGS84 a grid shift file is required, 
but as you point out
reasonable estimate of the geographic accuracy of active lines in 
CONUS would be 25 m RMS
any differences from a crude conversion and a proper one are going to be 
swamped by the RMS error.


This also means that the differences between NAD83 and WGS84 are 
immaterial within the CONUS for this dataset, and that decently 
rectified imagery is much more accurate than it.



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[Talk-us] Routing on Ferries

2014-12-31 Thread Clifford Snow
A Scout note, http://www.openstreetmap.org/note/294192 complains of routing
problems when a ferry is required.  A user of the OSM-based Scout app
reported the following possible map error: will not use ferry route. avoid
ferry not checked.  Is that a problem limited to Scout, or is there
something we should be checking for?

BTW - I've taken this ferry from Edmonds to Kingston, WA a number of times.
It is a great trip during nice weather.

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Imports-us Digest, Vol 24, Issue 1

2014-12-31 Thread stevea

(cross-posting from imports-us to talk-us)


On 12/31/2014 1:48 PM, stevea wrote:

 That is true, thank you Nathan Proudfoot.  For the Union Pacific, I
 was disappointed that their web site requires a (UP employee?) login
 and password to gain access to their geographic rail data.  BNSF seems
 a bit better (providing high level rail maps at a nationwide
 glance), and other railroads are probably somewhere around you get
 what you get, but please do take Nathan's good advice and seek data
 directly from a rail entity as a good first strategy for obtaining
 track/lead/line/subdivision names, for example.


Paul Norman writes:

In my experience these types of companies seldom provide anything under
a usable license - is this different for US-based rail company databases?


This is a very important consideration; all data 
entered into OSM (from such sources) must be ODBL 
compatible.  As I look at, for example, the BNSF 
(carload_map.pdf) file that Nathan Proudfoot 
pointed to, it definitely says © 2011 BNSF 
Railway so this is the sort of source OSM cannot 
use to originate data.


However, federal data or data from states where 
there are liberal public records law (for 
example, the California Public Utilities 
Commission Rail Crossing List listing Primary 
Rail Organization as top-level entities and the 
names of their subdivision), I believe these 
public sourced data origins are perfectly OK as 
they originate as public data at the nexus of a 
Citizen of that state placing the data into OSM 
as a volunteer who has agreed to the Contributor 
Terms.


Be careful, everybody.  Public data in a public 
record data friendly state?  OK.  Copyrighted 
data directly from (say) the website of a rail 
company?  Not OK.


What I'm not quite sure about are federal records 
such as FRA records (as I believe Oak Ridge data 
are).  These would be covered under, say, a FOIA 
request, and so are quite similar to the same 
nexus argument as state records, only under 
federal law, not state law.


Happy New Year,
SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Routing on Ferries

2014-12-31 Thread Richard Welty

On 1/1/15 1:39 AM, Clifford Snow wrote:
A Scout note, http://www.openstreetmap.org/note/294192 complains of 
routing problems when a ferry is required.  A user of the OSM-based 
Scout app reported the following possible map error: will not use 
ferry route. avoid ferry not checked.  Is that a problem limited to 
Scout, or is there something we should be checking for?


BTW - I've taken this ferry from Edmonds to Kingston, WA a number of 
times. It is a great trip during nice weather.

the one routing issue i'm familiar with is that frequently ferry access
uses highway=service, and some routing applications try to avoid
service roads as much as possible.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS  IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] Routing on Ferries

2014-12-31 Thread Natfoot
Clifford,
When talking to the Scout team this summer it was mentioned as an issue.
Also Scout wont route across access roads and if there is an access road
leading up to the dock/portal then no route. you will notice that it is
listed as primary road in Edmonds and Kingston.


Nathan P

On Wed, Dec 31, 2014 at 10:39 PM, Clifford Snow cliff...@snowandsnow.us
wrote:

 A Scout note, http://www.openstreetmap.org/note/294192 complains of
 routing problems when a ferry is required.  A user of the OSM-based Scout
 app reported the following possible map error: will not use ferry route.
 avoid ferry not checked.  Is that a problem limited to Scout, or is there
 something we should be checking for?

 BTW - I've taken this ferry from Edmonds to Kingston, WA a number of
 times. It is a great trip during nice weather.

 Clifford

 --
 @osm_seattle
 osm_seattle.snowandsnow.us
 OpenStreetMap: Maps with a human touch

 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us