[Talk-us] TIGER tracing layer updated to 2015 release
Last week the US Census Bureau released the 2015 version of TIGER. This
afternoon I updated the data in the set of tracing tiles that Mapbox hosts.
As before, at zoom level 16 and up, it shows the complete TIGER streets,
and at zoom levels 12 through 15, it shows TIGER minus dynamically
subtracted OSM so you can more easily find TIGER streets that are missing
in OSM.
The tile URL has not changed, so if you are using iD or another editor that
pulls from editor-imagery-index, you already have the new data. If not, you
can manually enter the tile URL:
https://a.tiles.mapbox.com/v4/enf.e0b8291e/{z}/{x}/{y}.png?access_token=pk.eyJ1IjoiZW5mIiwiYSI6IkNJek92bnMifQ.xn2_Uj9RkYTGRuCGg4DXZQ
Eric
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
This would match how people usually talk about things like I-465 around Indianapolis, ignoring all the other routes that are also routed along it, but it doesn't work quite so well when there are co-signed routes that persist for long distances where people refer to the paired name. I think Highway 1-9 in New Jersey, which is both US 1 and US 9, is the main example, but Highway 12-18 in Madison, WI (US 12 and US 18) also comes to mind. Eric On Sat, Dec 21, 2013 at 12:21 PM, Peter Davies peter.dav...@crc-corp.comwrote: A further thought in favor of using the way ref tag simply to indicate the principal route designator, leaving any multi-banded secondary routes that share the way to be defined only in the relations, is that we would be making the US more consistent with road numbering and mapping practices in other countries. In the UK, for example, multi-banding does not occur because the Department of Transport allows numbered roads to have breaks (gaps) where they follow other routes. For example, the M62 from Liverpool to Leeds and Hull no longer exists across the Manchester M60 Ring Motorway section. Drivers follow M62 from Liverpool, then take the Manchester Ring Road M60, and then pick up the M62 again across the Pennines to Leeds and Hull. In a similar example on the primary route system, the A49 joins with the A5 around the Shrewsbury bypass, and then separates and strikes off north again after a few miles. This approach is universal in the UK, and is also standard practice in many other countries. In the UK and elsewhere, the shared section is identified by a single principal route designator. Important secondary UK designations can be shown on green primary route signs, e.g., Oswestry A5; Leominster (A49). This is interpreted as A5 changing to A49 for Leominster. On UK maps of all kinds, only A5 is marked on the common section. Thus, OSM currently tags ways on the common section simply with ref A5. We could do the same here in the US if we swapped out US 202;ME 11;ME 17;ME 100 for just US 202 in the way ref. (As it happens, only US 202 IS currently coded on Western Avenue in Augusta, and perhaps we should leave it that way?) I believe that US state DOT practices of multi-banding might be made more user friendly if we could focus on the principal designated route in the way ref tag. It doesn't really help many drivers to know that I 80 in parts of Wyoming is also US 30. My thoughts are that the Interstate system rightly swamps out noise from older transcontinental routes that have little travel significance in the 21st century. It could be that these secondary sign shields are an unwarranted expense that may gradually fade away. But those who still want to show secondary banding would be able to do so using the route relations. We would also be eliminating the practice of cramming multiple data elements into a single tag. Personally I'm not a purist about such things, but I've seen some people shudder at the current U.S. way ref tag practices of listing route refs one after another in a single data field. Peter On Sat, Dec 21, 2013 at 10:46 AM, Peter Davies peter.dav...@crc-corp.comwrote: I think it useful to spin off this topic from the long and still unfinished debate about directional roles in relations. I hope it can be agreed more quickly than the cardinal directional roles issue! The question is how to handle US roadway routes that are double, triple or even quad-banded, having multiple route designators. Some OSM mappers call this topic route overlaps. I might call it information overload. On most maps, renderers simply show ALL the shields. But is it helpful to have roads peppered with conflicting information about the route number? Who gains by knowing that Western Avenue, Augusta, Maine is US 202, ME 11, ME 17 and ME 100? Isn't this really confusing and unhelpful for most map users? Now, if it's confusing on a map, just think how confusing it is in a navigation system or a traffic event info system. Look out for a crash on US 202 eastbound / ME 11 northbound / ME 17 northbound / ME 100 eastbound (Western Avenue) in Augusta. We need to know which route designator is the most important one, and to use mainly or only that one when talking to drivers. This is not something that OSM needs to make up. The principal designator should the top shield, left shield or top-left shield on traffic signs. State DOTs and police also face this same problem, and every multi-banded route section in states with which I work already has an official principal designator. We need a way of capturing this in OSM for use in nav systems and info systems, as well as (perhaps) for ridding simple maps of route shield clutter. Martijn van Exel and perhaps others have suggested that we should use only relations to define route designators on ways, and not way ref tags. However I can't see how the relations alone
Re: [Talk-us] Tags to use for chain stores in the United States
I don't know if it catches all the chains you are interested in, but Aaron Lidman has been collecting the consensus tag schemes for various business names for presets in iD. I think his current compilation is https://github.com/systemed/iD/blob/master/data/name-suggestions.json Eric On Wed, Dec 11, 2013 at 10:49 AM, Will Skora skorasau...@gmail.com wrote: Hi, At past OSM meetups that I've organized, new mappers have asked me what shop=* tags to use for several chain stores in the USA and I had not found any clear or consistent practices of what tags to use for these stores and even as a relatively experienced mapper, I wasn't sure what tags to encourage them to use. I am writing to hear what you've used, which ones are most popular, and perhaps the US community could build a consensus on them (gasp!). For example, several chain stores that we have wondered about include: K-Mart, Target, Wal-Mart, Dollar General, Dollar Tree, Family Dollar, 'Bed, Bath, and Beyond'; TJ Maxx; Marshall's; Radio Shack; Meijer's; Kohl's; Costco; BJ's; and Big Lots. I know there's taginfo (including one for the US! taginfo.openstreetmap.us) but unfortunately, it doesn't let you find out what tag combinations are being used with a name=* (For example, finding what tag is used most often with name=Dollar-General). Regards, Will Skora ___ 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
Re: [Talk-us] A new tracing layer for TIGER 2013
Thanks for the feedback about colors in JOSM. I can clearly see now that what made for good contrast in iD is hard to use in JOSM. I'll try some new styles today and make sure they stand out in both editors. I think maybe the answer is to put a casing around the line so that it has a different look even if the color is similar. Eric ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A new tracing layer for TIGER 2013
Thanks for the report! Can you be a little more specific about what you want to show more contrast: * Between TIGER roads and iD or JOSM roads? * Between TIGER roads and the aerial imagery? * Between TIGER roads and railroads? * Between different classes of TIGER roads? * Something else? If you have a screenshot of two things that look alike to you and that should be distinguishable, that would be a big help. I don't think the 2012 TIGER layer uses any color at all, unless the color was too subtle for me to see too. Eric On Mon, Dec 9, 2013 at 1:52 AM, Paul Johnson ba...@ursamundi.org wrote: On Sunday, December 8, 2013, Eric Fischer wrote: There are only a few colors involved: streets are yellow and railroads are blue, and both are a little brighter if they have changed since the 2006 data. Service roads are drawn a little thinner than the rest, following the example of the 2012 TIGER layer. More contrast, please! I can't tell the difference between the colors. The change in colors are too subtle to tell apart. And that's coming from me, I have a JOSM stylesheet that colors maxspeed=* to color the same as JOSM colors GPX for car speeds, and I can tell the difference between 30, 35, 40, and 45 MPH at a glance. ___ 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
Re: [Talk-us] A new tracing layer for TIGER 2013
Thanks. I'll try to make that clearer in the next revision. Eric On Mon, Dec 9, 2013 at 11:02 AM, Paul Johnson ba...@ursamundi.org wrote: Between changed and unchanged. On Mon, Dec 9, 2013 at 8:52 AM, Eric Fischer e...@pobox.com wrote: Thanks for the report! Can you be a little more specific about what you want to show more contrast: * Between TIGER roads and iD or JOSM roads? * Between TIGER roads and the aerial imagery? * Between TIGER roads and railroads? * Between different classes of TIGER roads? * Something else? If you have a screenshot of two things that look alike to you and that should be distinguishable, that would be a big help. I don't think the 2012 TIGER layer uses any color at all, unless the color was too subtle for me to see too. Eric On Mon, Dec 9, 2013 at 1:52 AM, Paul Johnson ba...@ursamundi.org wrote: On Sunday, December 8, 2013, Eric Fischer wrote: There are only a few colors involved: streets are yellow and railroads are blue, and both are a little brighter if they have changed since the 2006 data. Service roads are drawn a little thinner than the rest, following the example of the 2012 TIGER layer. More contrast, please! I can't tell the difference between the colors. The change in colors are too subtle to tell apart. And that's coming from me, I have a JOSM stylesheet that colors maxspeed=* to color the same as JOSM colors GPX for car speeds, and I can tell the difference between 30, 35, 40, and 45 MPH at a glance. ___ 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] A new tracing layer for TIGER 2013
As was just announced on the MapBox blog (
https://www.mapbox.com/blog/openstreetmap-tiger/) there is a new
OpenStreetMap tracing layer for 2013 Census Bureau TIGER map data in the US.
The main reason for it, aside from incorporating this year's TIGER changes,
is to provide different features at different zoom levels:
* At zoom 16 and up, like the TIGER 2012 layer, it shows all the current
TIGER roads so that they can be compared with OpenStreetMap and the
discrepancies corrected.
* At zoom 12-15, it shows only the TIGER roads that have been changed since
the import in 2006, with the current state of OpenStreetMap masked out, so
you see only the places where TIGER has been changed (and presumably
corrected) but OpenStreetMap hasn't. This should give an easier overview of
what places need attention.
* At zooms below 12, like the Battle Grid, it also shows discrepancies
between OSM and TIGER, but simplified because the individual streets are
too small to draw in detail. It's a static calculation that will get
periodically refreshed, but not instantly, as OpenStreetMap changes.
The tile URL is http://{switch:a,b,c}.
tiles.mapbox.com/v3/enf.ho204tap,enf.ho20a3n1,enf.game1617/{zoom}/{x}/{y}.pngbut
as the comma-separated list in the URL suggests, it is actually a
composite of three layers that work together:
TIGER streets/changes:
https://a.tiles.mapbox.com/v3/enf.ho204tap/page.html?secure=1#14/40.3648/-86.8654
OpenStreetMap mask:
https://a.tiles.mapbox.com/v3/enf.ho20a3n1/page.html?secure=1#14/40.3648/-86.8654
Low zooms:
https://a.tiles.mapbox.com/v3/enf.game1617/page.html?secure=1#11/40.3648/-86.8654
In the pull request for iD (https://github.com/systemed/iD/pull/2010) Ian
Dees pointed out that the abbreviations in street names should expanded and
that it would be good to also include house numbers. I'll be updating the
vector data with expanded names in the next few days and will add the house
numbers as soon as I can. Please let me know if you see anything else that
ought to be better.
Eric
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A new tracing layer for TIGER 2013
Thanks for the feedback!
There are only a few colors involved: streets are yellow and railroads are
blue, and both are a little brighter if they have changed since the 2006
data. Service roads are drawn a little thinner than the rest, following the
example of the 2012 TIGER layer.
I actually already have the name expansion ready (thanks to Paul Norman and
Toby Murray) and just need to generate and upload the new tiles.
The code for this one is part of
https://github.com/ericfischer/tiger-deltaand in particular
https://github.com/ericfischer/tiger-delta/blob/master/get-county-delta2
In the screenshot you posted, my intent was not to say that the OSM streets
shown were outdated, but instead to show that the good parts of the TIGER
data are already in OSM. At zoom level 16 and beyond, like the TIGER 2012
layer, this layer shows all the streets in TIGER, whether or not they are
also mapped in OSM. It's only if you zoom out to
http://www.openstreetmap.org/edit#map=15/47.8945/-122.2455 or lower that
streets that are already in OSM will be masked out from those in TIGER.
Would you find it useful to have TIGER-minus-OSM available even when zoomed
all the way in? I thought since all the OSM streets are already visible in
the editor's own display that it would be distracting to draw them twice.
But I am biased because iD shows the live street data at z16+ and doesn't
at zooms 16, and maybe the transition looks weird in JOSM.
Eric
On Sun, Dec 8, 2013 at 6:32 PM, Clifford Snow cliff...@snowandsnow.uswrote:
Eric,
One other issue. Here is a link,
https://www.dropbox.com/s/v1je9m490c0yns4/Why%20Flagged.png, to an area,
http://osm.org/go/WJIDU~lZs-- near me. You can ignore the crazy tiger
data on the right! However, notice the streets, 114th St SW, 115th St SW,
8th Pl W and 8 Ave W. There all all existing, but were flagged as being
outdated. Is it because they are not exactly the same as the tiger data?
BTW, I really appreciate the work you are putting into helping us fix
streets along with Martijn's Battlegrid.
Clifford
On Sun, Dec 8, 2013 at 11:04 AM, Clifford Snow cliff...@snowandsnow.uswrote:
Eric,
A big help would be to have an understanding of how ways are displayed on
the overlay. I see different shapes and colors. What do they represent?
I can help with the name expansion. I have a fair number of abbreviations
that I've used in Washington State.
BTW is your code at https://github.com/ericfischer/osm-tiger-update?
Clifford
On Sun, Dec 8, 2013 at 10:42 AM, Eric Fischer e...@pobox.com wrote:
As was just announced on the MapBox blog (
https://www.mapbox.com/blog/openstreetmap-tiger/) there is a new
OpenStreetMap tracing layer for 2013 Census Bureau TIGER map data in the US.
The main reason for it, aside from incorporating this year's TIGER
changes, is to provide different features at different zoom levels:
* At zoom 16 and up, like the TIGER 2012 layer, it shows all the current
TIGER roads so that they can be compared with OpenStreetMap and the
discrepancies corrected.
* At zoom 12-15, it shows only the TIGER roads that have been changed
since the import in 2006, with the current state of OpenStreetMap masked
out, so you see only the places where TIGER has been changed (and
presumably corrected) but OpenStreetMap hasn't. This should give an easier
overview of what places need attention.
* At zooms below 12, like the Battle Grid, it also shows discrepancies
between OSM and TIGER, but simplified because the individual streets are
too small to draw in detail. It's a static calculation that will get
periodically refreshed, but not instantly, as OpenStreetMap changes.
The tile URL is http://{switch:a,b,c}.
tiles.mapbox.com/v3/enf.ho204tap,enf.ho20a3n1,enf.game1617/{zoom}/{x}/{y}.pnghttp://tiles.mapbox.com/v3/enf.ho204tap,enf.ho20a3n1,enf.game1617/%7Bzoom%7D/%7Bx%7D/%7By%7D.pngbut
as the comma-separated list in the URL suggests, it is actually a
composite of three layers that work together:
TIGER streets/changes:
https://a.tiles.mapbox.com/v3/enf.ho204tap/page.html?secure=1#14/40.3648/-86.8654
OpenStreetMap mask:
https://a.tiles.mapbox.com/v3/enf.ho20a3n1/page.html?secure=1#14/40.3648/-86.8654
Low zooms:
https://a.tiles.mapbox.com/v3/enf.game1617/page.html?secure=1#11/40.3648/-86.8654
In the pull request for iD (https://github.com/systemed/iD/pull/2010)
Ian Dees pointed out that the abbreviations in street names should expanded
and that it would be good to also include house numbers. I'll be updating
the vector data with expanded names in the next few days and will add the
house numbers as soon as I can. Please let me know if you see anything else
that ought to be better.
Eric
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
--
Clifford
OpenStreetMap: Maps with a human touch
--
Clifford
OpenStreetMap: Maps with a human touch
Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?
On Tue, Nov 26, 2013 at 5:52 AM, Richard Welty rwe...@averillpark.netwrote: if the good tracks are on the microSD card then that means you can minimize cycles on the mini-USB port, as you can remove the microSD and use an external reader. this should lead to a longer useful life for the unit (yes, i'm really fed up with having two dead Nuvis because of busted mini USB ports). The caveat I would give about that is that on my eTrex Legend, the SD card slot started getting flaky long before the USB port had any trouble. I think that's worse than flaky USB, because there's no visible indication (until you switch to the map view and discover that the map didn't load) that the SD card didn't mount at boot and the receiver hasn't been logging tracks to it. Eric ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?
I've been using a Garmin eTrex 20 for most of the past year and am pretty happy with it. Compared to the earlier eTrex Legend HCx, it supports GLONASS, gets better battery life (about 40 hours of use on two AA batteries), gets a fix much faster after powering on, has more attractive (but slower) map rendering, and can log tracks and use OSM (Lambertus) base maps without having to install an SD card. The tracks are definitely higher quality than from phones I've tried (mostly Samsung Galaxy S and Galaxy Nexus) but newer phones might do better. Eric On Sun, Nov 24, 2013 at 6:17 PM, Joseph R. Justice jayare...@gmail.comwrote: [I am subscribed to Talk-US and will see responses to this message sent to that list. -- J] So, I've been thinking about getting involved with OSM, particularly in terms of improving the map in the area I live in (Fort Lauderdale, FL, USA). Looking through the wiki, the Beginner's Guide, and all of that, it seems like one of the most popular and useful ways to do that is to collect and upload GPS traces. That's something I can do on the ground in my area, and at a pretty detailed level because I'd be doing it on foot. I have several Android devices that contain GPS functionality. (Currently, I have and actively use a Google Nexus 7 (2013 ed) tablet and a Samsung Galaxy S II on the Virgin Mobile USA (Sprint) network, and less often a Toshiba Thrive 10 tablet; I have a couple of other devices that are not currently working.) However, I'm thinking that their capability to make accurate and precise GPS measurements might not be as good as that of a dedicated GPS device. Also, I understand that having GPS signal reception separated from that of the other functionality of a Android device will help improve the battery life of the Android device. Therefore, I am thinking about getting some sort of GPS receiver, either a standalone one and / or one that can communicate via Bluetooth to my Android devices. However, I do not have any experience with dedicated GPS devices per se. To that end, I am wondering if anyone here would wish to offer suggestions on GPS devices that are currently available in the US which I should consider. I have been doing some research, but there's a lot of possibilities out there, both well-known name brands with lots of advertising and not so well known brands, and like I said I do not have personal experience with this sort of thing. I was originally considering getting just a pure receiver, with no display capability and perhaps not even any logging capability, e.g. something that would simply receive and process a GPS signal and relay the results (e.g. coordinates, etc) via Bluetooth to an Android device, which would then be responsible for everything else. However, I've subsequently considered that having a GPS device which could be useful by itself without needing anything else might be more useful in general, even if it costs somewhat more. So, I am not restricting myself to considering just GPS receiver-only or receiver-plus-logging-only devices. I'm pretty sure that even if I get a device capable of working as a standalone device, that I would want it to be able to communicate with my Android devices, so I'll probably want Bluetooth (or possibly WiFi but I suspect that is more costly and power-hungry) no matter what. I'll probably want USB *if* I get a device capable of making an internal log, so I can easily transfer data to my PCs. (I don't know that it makes sense or is even feasible to try to connect a GPS device to my Android devices via USB.) I'll probably want something capable of receiving signals both from the US and Russian (GLONASS) GPS systems, since they're both available and it looks like using GLONASS can help provide a more precise location fix. (I assume devices capable of receiving signals from the forthcoming European and Chinese systems are not yet available.) I'll probably want something capable of receiving whatever publicly- and freely-available GPS augmentation / refinement signals are available. (I know about WAAS run by the FAA, and I think there's also something run by the Coast Guard; I'm not sure if there's anything else in the US that's freely available.) It looks like that, at least to an extent, the more channels the better. In general, I'll probably want something that is as accurate and precise as is feasibly affordable for and available to a non-professional working alone. (I've seen that there's very precise professional survey-grade equipment out there, but it's probably way beyond anything I'd be willing to pay at this time. Likewise, a lot of the pro stuff appears to call for a base station unit and a rover unit, which would realistically require a minimum of two people; I'm going to be doing this by myself. However, if I'm going to do this, I want to generate the best data that is feasible for me to collect.) If I get a
Re: [Talk-us] Freeway directions
California gives State, US, and Interstate roads unique signed numbers within the state, but not all states do. Interstate 64 in southern Indiana is close enough to State Road 64 to cause frequent confusion. Eric On Thu, Oct 17, 2013 at 8:52 PM, Tod Fitch t...@fitchdesign.com wrote: On Oct 17, 2013, at 6:11 PM, Nathan Mills wrote: On 10/17/2013 1:03 PM, Richard Welty wrote: If my GPS tells me to turn right at the entrance to East Interstate Whatever and the sign says North Interstate Whatever, I'm going to be confused and wonder if I'm actually making the correct turn. Even more so if it's a printed list of directions. I can't say for the urban auxiliary (three digit) freeways, but the single and double digit Interstates all seem to have on ramp signs that use their nominal direction rather than the compass direction at that particular location. At least that is my understanding from what I've read about the rules and conventions that are supposed to be used and I have never noticed an exception. For what it is worth, it is my understanding that within a state the use of a particular number, at least outside of triple digit urban beltways and penetration Interstates, is supposed to be unique. So if I-10 goes through your state, there will be no US10 nor a state highway 10. I haven't paid much attention to this in other states I've visited but it seems to hold true for California. If true throughout the US then it could be used to help validate highway route numbers. Confusion in California comes in two flavors: In Southern California there is a popular tendency to call freeways by a name (e.g. The Ventura) and use the actual direction the road goes for that named segment (east/west for the Ventura) when giving directions. But the named segment might be on a US or Interstate with a different nominal direction. This bit me years ago when we were mailing out wedding directions and I assumed the on ramp from the hotel area would be labeled for the eastbound Ventura Freeway when, upon checking, it turned out to be labeled for southbound US101. In the San Francisco Bay Area the confusion comes from the fact that the only Interstate to enter the area is I-80. So all the urban auxiliary (three digit) freeways have to have a suffix of 80 (even number implying east/west) even if the road is north/south. So we have 280, 580, 680, 880, etc. all going in different directions. Southern California avoids this by having I-5, I-8, I-10 and I-15 enter the area, so I-210 is basically east/west while I-405 and I-215 are basically north/south. -Tod ___ 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
Re: [Talk-us] Future Interstate Relations
Here's someone's picture of a Future 86 shield from a few years ago: http://www.flickr.com/photos/iccdude/5516141266/ And also some band by that name with nonstandard FUTURE lettering on the shield: http://www.flickr.com/photos/89048316@N00/1815241606/ Eric On Thu, Jul 11, 2013 at 10:57 AM, James Mast rickmastfa...@hotmail.comwrote: Is there picture proof of how they are signing it? -James Date: Wed, 10 Jul 2013 21:43:47 -0400 From: kken...@nycap.rr.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] Future Interstate Relations On Wed, Jul 10, 2013 at 7:40 AM, Phil! Gold phi...@pobox.com wrote: Given that previous list consensus was for tagging of the form: network=US:I:Future ref=number modifier=Future and that only one person offered a variant opinion this time around, I'd recommend tagging as above. Also, from your earlier emails, I have future interstates 26, 73, 74, and 840. Are there any others? 86 in New York, so signed for various segments of NY 17. https://www.dot.ny.gov/regional-offices/multi/i-86 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updating unchanged TIGER imports to TIGER 2013
Thanks. I just joined the list and will send a message there. Eric On Sat, Mar 16, 2013 at 4:59 PM, Serge Wroclawski emac...@gmail.com wrote: Eric, I'm in general favor of your idea. I think that if we can get more accurate, up to date data out of TIGER, then we should. I'd strongly encourage you to join us on the OSM US Import Committee list: http://lists.openstreetmap.org/listinfo/imports-us - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updating unchanged TIGER imports to TIGER 2013
Thanks for the helpful comments. At least anecdotally, I think I have actually seen the TIGER merge lead to more anomalies in gridded areas than in hills, maybe because people feel more comfortable making minor edits to mostly-regular grids. I completely agree that any new ways imported from TIGER will have to be reviewed manually, if for no other reason because they generally don't connect to any existing node. I am intending to produce the additions and adjustments as separate .osc files that can be examined for correctness in JOSM before being applied. Would people generally be comfortable with accepting node relocations that don't cause any ways to overlap themselves without extensive manual review, and only carefully reviewing additions? Eric On Tue, Mar 12, 2013 at 2:18 PM, Richard Welty rwe...@averillpark.netwrote: On 3/12/13 5:00 PM, Mike N wrote: On 3/11/2013 10:10 PM, Eric Fischer wrote: The results of application will depend on both the original data and the 2012 data. For layouts with 'regular geometry' - roughly square, rectangular, or rhomboid layouts, the results will be generally good. For curved roads with poor original TIGER geometry, I would expect the result to be very irregular without manual correction. I've seen this type of road network in very hilly or mountainous areas. this level of mis-alignment is common in Upstate NY: http://www.openstreetmap.org/?**lat=43.51916lon=-73.6955** zoom=15layers=Mhttp://www.openstreetmap.org/?lat=43.51916lon=-73.6955zoom=15layers=M the example is from Warren County. i've seen worse in West Virginia and Arizona. Ideally, all the new street data should be reviewed before bringing it in; depending on the origin, most of it needs to have the alignment tweaked and connectivity verified against Bing Aerials. It would be nice to be able to view the results in JOSM before uploading them, even if another tool is used for upload; I'm not sure how to do that. if the results are in an osm xml format, then JOSM can just load it up. i like the idea, but there needs to be a manual quality control step so we don't make things worse while trying to make them better. richard __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updating unchanged TIGER imports to TIGER 2013
That sounds like a good idea to me. I want to be careful not to break anything. Eric On Tue, Mar 12, 2013 at 6:34 PM, Richard Welty rwe...@averillpark.netwrote: On 3/12/13 9:32 PM, Eric Fischer wrote: Thanks for the helpful comments. At least anecdotally, I think I have actually seen the TIGER merge lead to more anomalies in gridded areas than in hills, maybe because people feel more comfortable making minor edits to mostly-regular grids. I completely agree that any new ways imported from TIGER will have to be reviewed manually, if for no other reason because they generally don't connect to any existing node. I am intending to produce the additions and adjustments as separate .osc files that can be examined for correctness in JOSM before being applied. Would people generally be comfortable with accepting node relocations that don't cause any ways to overlap themselves without extensive manual review, and only carefully reviewing additions? i think the best approach is to manually review early ones to develop some comfort level with the non-overlapping case. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Updating unchanged TIGER imports to TIGER 2013
Hi everyone. At the time OpenStreetMap imported the US Census TIGER map data, the Census was in the middle of their Accuracy Improvement Program that greatly improved the alignment of TIGER features in many areas for the 2010 census. Many of the TIGER corrections have since also been applied to OpenStreetMap, particularly in major metro areas, but not generally not systematically, and many others, particularly in rural areas, have not been applied. I would like to update OpenStreetMap with as many of the corrections that have been made to TIGER as can be applied to Open StreetMap without altering anything that has been edited directly in OSM. In most cases this just means moving unedited OSM nodes that came from TIGER to the positions that TIGER currently indicates, although in some cases TIGER edges have had nodes added or removed, so the corresponding OSM ways must also have nodes added or removed. I don't propose to delete or move any intermediate points that have been linked to other OSM ways, or to move any nodes that have been moved in OSM since the TIGER import. I also don't propose to change any tags other than an addition to indicate the source of the new location data. Although this process will never change the topology of the network, there can occasionally be some odd-looking results where someone has moved (but not to the correct location) an OSM node that connects to an updated TIGER node, sometimes causing streets to have abrupt turns or to cross over themselves. I'm not sure what to do about these cases other than call them out and fix them manually. There are also many cases where TIGER 2013 knows about streets that were not built or not mapped in TIGER 2006. Some of these have also been added by OSM contributors but many others have not been. I think the right thing to do for these is to generate speculative OSM equivalents, but rather than checking any of them in directly, use something like MapRoulette to review each of them to see whether or not it ought to be adopted. The code I've been writing to generate the XML for these changes, mostly only tested so far on a few Indiana counties, is at https://github.com/ericfischer/osm-tiger-update A rendering of what the changes look like in those counties is at http://www.flickr.com/photos/walkingsf/8549176793/ Please let me know what you think of the idea and if there is a better way to do it. Thanks, Eric ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updating unchanged TIGER imports to TIGER 2013
Sorry not to be clear! Here is the .osc output for those four Indiana counties. (I hope I have all the formatting right. Osmconvert doesn't seem to apply my added tag, although it changes the nodes for the way, and I don't understand what is going wrong.) https://docs.google.com/file/d/0B6gxjm4UN7Vjb09hd0RMTHJNaVU/edit?usp=sharing Eric On Mon, Mar 11, 2013 at 8:30 PM, Paul Norman penor...@mac.com wrote: I’m not exactly following the logic in the code. Could you produce a .osc file result with the changes that it would make? ** ** *From:* Eric Fischer [mailto:e...@pobox.com] *Sent:* Monday, March 11, 2013 7:11 PM *To:* talk-us@openstreetmap.org *Cc:* Michal Migurski; Alex Barth *Subject:* [Talk-us] Updating unchanged TIGER imports to TIGER 2013 ** ** The code I've been writing to generate the XML for these changes, mostly only tested so far on a few Indiana counties, is at https://github.com/ericfischer/osm-tiger-update A rendering of what the changes look like in those counties is at http://www.flickr.com/photos/walkingsf/8549176793/ ** ** Please let me know what you think of the idea and if there is a better way to do it. Thanks, ** ** Eric ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
