Re: [Talk-us] Denver RTD's public_transport growth
Jay Johnson wrote: > The authoritative source for railroad GIS data is usually considered to be > BTS: https://www.bts.gov Thank you, Jay! That's a very rich website, I'm now fumbling my way through it and I think I can find the "platform/stop" locations I'm looking for, but it may take some data massaging to get those into OSM in a straight line. I find it kind of neat (circular logic?) that OSM is at least partly used as a basemap layer on this site's geo browser, although as I drill down to the data I'm looking for, the US DOT web site "becomes" a US DOT-branded site in the opendata.arcgis.com domain. OK, whatever; ArcGIS' open data portal using OSM doesn't surprise me, and they do properly attribute OSM. Some of these data appear to be a national agglomeration of transit-authority-produced GTFS feeds, which is/was another method by which I might have obtained these data (they are published either by the transit authorities themselves or by similar, non-governmental, often academic sites which collate the data). I'm sort of slapping my forehead that I didn't think of GTFS data first, as I mentioned GTFS in a 2014 SOTM-US talk I gave on national bicycle routing; GTFS are really useful data, and them finding their way into OSM is a fairly natural thing to happen (given time, and here we are). I'm also appreciative that the bts.gov data are quite fresh; it looks like they started the project in 2016 and some of the data are dated February, 2018. Great! > When I worked at BNSF, that is what was used to initially populate the > linework for our rail feature class. I would have thought BNSF (and other Class I carriers) had their own maps of their own rail lines. Interesting that they use a .gov site (and data) to "populate the linework." Again, seems sort of circular, as the rail line data had to originate from somewhere. > Class I railroads (the very large ones) are generally regulated by the > Federal Railroad Administration. PUC is for telecom, electric and gas. I had great luck with California's PUC and rail data: one was a statewide "crossing spreadsheet" that listed road/rail crossings and allowed OSM (me, in this case) to replace (at least in California) our rough TIGER rail data with proper Subdivision names. That took me some time to curate, but our California/Railroads wiki and useful products like OpenRailwayMap and OpenPublicTransportMap are all the better for it wherever OSM volunteers do this work. The California PUC also publishes an excellent PDF/hypertext of passenger rail data (a link to it is in our wiki) right down to the level of speed limits on segments and signal/switch names. That's pretty ambitious (especially in a state with as much rail as California) and I haven't incorporated those data into OSM, but the links are there for anybody who wants to bite that off and chew (and chew, and chew). Part of what I'm doing is "building community" by launching Colorado/Railroads (as another statewide wiki "seed" for good rail documentation) in the hopes of inspiring others to do the same in their states. (We're up to ten or eleven states now with alpha/beta-level rail wiki pages). And, I was hoping that OSM volunteers would take heed to "Map Your Train Ride!" to get more platform/stop data into OSM's passenger train routes. But, there is more than one way to do all of these things, of course. Fantastic there are so much good data "out there" and that we have people reading this list who know where to find them! Thanks again, SteveA ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address data for Miami Florida United States
Mr. Rasmussen, Thanks for the offer! I definitely need help. :) I looked, and failed to find, the layer without unit#. That's what I thought would be preferred. Thanks for spotting it. I don't see why we would search for a specific unit on a map. When I navigate, I would just want directions to "1234 NW 33rd Ct", not "1234 NW 33rd Ct Apt 6". If you know of a good reason for the unit #s, let me know. It doesn't matter to me, since I don't need navigation in Miami. :D If you think 600k points is big, imagine the building footprints. :) It's available, if required. Heck, they even make a 3d building layer available. But I don't think we'll enjoy the size. I knew the license is not a problem. However, I saved that email just in case it comes up. I'm going to read the info Mr. Juhász provided. Unfortunately, I'm way behind here. Also, I replied to all b/c I think that's what I'm supposed to do. However, I don't want to 'bug' people on the list. Hopefully, someone will let me know if this needs to go off-list. (_8'() ‐‐‐ Original Message ‐‐‐ On Wednesday, September 12, 2018 4:17 PM, Leif Rasmussen <354...@gmail.com> wrote: > Hi Mango, > I have quite a lot of experience with address imports, and would love to help > with Miami. I have visited Miami several times, and have grown a liking for > it. Adding addresses there would be a real pleasure. > There appears to be two address data sets - one with "addr:unit", and one > without. The [one with "addr:unit" > addresses](https://gis-mdc.opendata.arcgis.com/datasets/address-with-condo?geometry=-80.369%2C25.708%2C-80.365%2C25.709) > has 1,166,445 points, and the [one > without](https://gis-mdc.opendata.arcgis.com/datasets/eef6b33da60d47c0964387960c840eea_0?geometry=-80.274%2C25.715%2C-80.272%2C25.715) > has 586,171 points. Both of these should be considered. I would suggest > importing the one with condos, or "addr:unit" features if the quality is > good. Otherwise, I think that the dataset without addr:unit should be > imported. > Also, the license seems OK. According to the [Miami-Dade County Buildings > Import](https://wiki.openstreetmap.org/wiki/Miami-Dade_County_Large_Building_Import#Import%20Data), > the license is public domain, which they claim is true of all government > produced data in Florida. > The only issue I see with the data is the size. My laptop took 5 minutes to > open the address points (including addr:unit, so 1,166,445 nodes) and more > than 20 minutes to edit a single key. This could be worked around, though, > by splitting up the data. > I created a [wiki page for the > import](https://wiki.openstreetmap.org/wiki/Miami-Dade_County_Address_Import), > which is a step of the [Import > Guidelines](https://wiki.openstreetmap.org/wiki/Import/Guidelines). Sending a > proposal to the local community and imports mailing list will also be needed. > I hope that this import will end up working out! > Leif Rasmussen (_8'() Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, September 12, 2018 4:17 PM, Leif Rasmussen <354...@gmail.com> wrote: > Hi Mango, > I have quite a lot of experience with address imports, and would love to help > with Miami. I have visited Miami several times, and have grown a liking for > it. Adding addresses there would be a real pleasure. > There appears to be two address data sets - one with "addr:unit", and one > without. The [one with "addr:unit" > addresses](https://gis-mdc.opendata.arcgis.com/datasets/address-with-condo?geometry=-80.369%2C25.708%2C-80.365%2C25.709) > has 1,166,445 points, and the [one > without](https://gis-mdc.opendata.arcgis.com/datasets/eef6b33da60d47c0964387960c840eea_0?geometry=-80.274%2C25.715%2C-80.272%2C25.715) > has 586,171 points. Both of these should be considered. I would suggest > importing the one with condos, or "addr:unit" features if the quality is > good. Otherwise, I think that the dataset without addr:unit should be > imported. > Also, the license seems OK. According to the [Miami-Dade County Buildings > Import](https://wiki.openstreetmap.org/wiki/Miami-Dade_County_Large_Building_Import#Import%20Data), > the license is public domain, which they claim is true of all government > produced data in Florida. > The only issue I see with the data is the size. My laptop took 5 minutes to > open the address points (including addr:unit, so 1,166,445 nodes) and more > than 20 minutes to edit a single key. This could be worked around, though, > by splitting up the data. > I created a [wiki page for the > import](https://wiki.openstreetmap.org/wiki/Miami-Dade_County_Address_Import), > which is a step of the [Import > Guidelines](https://wiki.openstreetmap.org/wiki/Import/Guidelines). Sending a > proposal to the local community and imports mailing list will also be needed. > I hope that this import will end up working out! > Leif
[Talk-us] Whole-US Garmin Map update - 2018-09-11
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-09-11 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-09-11/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-09-11 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a >2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 130, Issue 17
SteveA, The authoritative source for railroad GIS data is usually considered to be BTS: https://www.bts.gov/ When I worked at BNSF, that is what was used to initially populate the linework for our rail feature class. Class I railroads (the very large ones) are generally regulated by the Federal Railroad Administration. PUC is for telecom, electric and gas. Jay On Thu, Sep 13, 2018 at 8:05 AM wrote: > Send Talk-us mailing list submissions to > talk-us@openstreetmap.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstreetmap.org/listinfo/talk-us > or, via email, send a message with subject or body 'help' to > talk-us-requ...@openstreetmap.org > > You can reach the person managing the list at > talk-us-ow...@openstreetmap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Talk-us digest..." > > > Today's Topics: > >1. Re: USPS Post Boxes (EthnicFood IsGreat) >2. Re: Denver RTD's public_transport growth (OSM Volunteer stevea) > > > -- > > Message: 1 > Date: Wed, 12 Sep 2018 18:29:23 -0400 > From: EthnicFood IsGreat > To: talk-us@openstreetmap.org > Subject: Re: [Talk-us] USPS Post Boxes > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Date: Wed, 12 Sep 2018 14:25:15 -0700 > > From: Peter Dobratz > > To: bhou...@gmail.com > > Cc: "talk-us@openstreetmap.org Openstreetmap" > > , 354...@gmail.com > > Subject: Re: [Talk-us] USPS Post Boxes > > > > It would be good to standardize on operator tags for the 4 major carriers > > as you mentioned. The logos for DHL, FedEx, and UPS have those exact > > letters in them, so if people map what they see, then they will end up > with > > those exact values. However, as mentioned, the USPS logo actually > contains > > the text United States Postal Service. > > > > I could be convinced to switch my tagging from United States Postal > Service > > to USPS. Are there any arguments to support the short form beyond it > being > > easier to type? > > [...] > > I would like to point out there are free, little utilities like > Typertask that will quickly expand a few keystrokes into many more > letters. This can greatly speed up typing long strings like "United > States Postal Service". > > Mark > > > > -- > > Message: 2 > Date: Wed, 12 Sep 2018 16:49:58 -0700 > From: OSM Volunteer stevea > To: talk-us > Subject: Re: [Talk-us] Denver RTD's public_transport growth > Message-ID: <3f4ca4b1-673d-4035-b268-122ee2c9b...@softworkers.com> > Content-Type: text/plain; charset=us-ascii > > On Sep 2, 2018, at 9:52 PM, OSM Volunteer stevea < > stevea...@softworkers.com> wrote: > > > > I "found something rectangular" and sketched in > http://wiki.osm.org/wiki/Colorado/Railroads which we might agree (as a > useful, communicative wiki) is "alpha-1" or so. > > Following up to my own post, (that wiki continues as "early alpha"), two > important tasks emerge: > > 1) Denver RTD's University of Colorado A Line (train) needs nodes/ways > added to OSM, tagged public_transport=platform to grow the route from > public_transport:version=1 to v2. Seeing this is a pretty > heavily-travelled passenger=suburban route=train, this shouldn't be too > difficult, and > > 2) TIGER Review of existing mainline freight rail (primarily mainline > BNSF routes Colorado Springs, Pikes Peak, Spanish Peaks and Walsenburg > Subdivisions) will need some additional authoritative data sources > (Colorado PUC?) to "untangle" them from UP lines: they have blurred so > much and are have gotten so confused that the original TIGER data are > virtually incomprehensible as they exist in OSM at present. > > Of course, keeping the wiki synced with the data in OSM is the whole > point. Then we go beta and eventually Colorado/Railroads become "a pretty > darn good set of statewide rail data, well-documented." One state at a > time, OSM rail data (from decade-old hoary TIGER data) do measurably and > demonstrably improve. > > Thanks, especially to Colorado OSMers/rail enthusiasts who have responded > so far, > > SteveA > California > > > -- > > Subject: Digest Footer > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > > -- > > End of Talk-us Digest, Vol 130, Issue 17 > > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
