Re: [Talk-us] Discardable TIGER tags
Wasn't someone working on importing address data from TIGER? I was under the impression that may have depended on tiger:tlid tags on objects already in OSM, but wasn't sure… On Jul 30, 2012 1:50 AM, Alan grunthos...@yahoo.com wrote: On Sun, 2012-07-29 at 16:21 -0500, Toby Murray wrote: tiger:tlid - there seems to be support for removing it although I do recall someone opposing it strongly in the past as Anthony mentioned. In theory it lets you link back to a specific TIGER object. In practice it seems minimally useful with way splitting/merging and a fairly high degree of certainty that an automated TIGER 2011+ reimport where this could actually be used is probably not going to happen I think removing it is fine for any changed way, for the reasons everyone else has mentioned. I oppose removing it for ways that are unchanged (which I understand is not the current proposal for JOSM; I'm just stating for the record). I still think it is valuable to leave ourselves any options for synchronization in the future. While an automated TIGER re-import isn't likely to happen, the tlid could be useful in the mystical grand conflation tools that people have proposed/discussed/drooled over. - Alan ___ 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] NYC administrative boundaries and Nominatim
On 7/30/12 5:11 AM, Kevin Kenny wrote: On 07/29/2012 11:56 PM, Skye Book wrote: Do we have a source for NYC administrative boundaries? http://www.nyc.gov/html/dcp/html/bytes/districtsmetadata.shtml there also should be boundaries in TIGER. most of the problems i've seen with nominatim and boundaries have to do with half-assed boundaries based on the USGS stuff. i've been gradually replacing boundaries in the capital district with TIGER based boundaries which are much better. i have no opinion on the boundaries in the nyc.gov site, it might be worthwhile to compare them with the boundaries from tiger. i can probably give you .osm files based on the tiger boundaries if you want them for that purpose. it'd be good to look at the spot where nyc boundaries end and match them up with the tiger boundaries to see how good the fit is. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On 7/30/2012 7:18 AM, David ``Smith'' wrote: Wasn't someone working on importing address data from TIGER? I was under the impression that may have depended on tiger:tlid tags on objects already in OSM, but wasn't sure… TIGER address data isn't nearly accurate enough to import into OSM. Addressing applications who want to use TIGER addressing for a rough geo-location estimate could just use a local TIGER address database to fall back on if OSM does not contain the address. I've often discussed importing updated road data from TIGER. The single case where TLID could be useful is matching un-named driveways to existing data, then applying a geometric correction to the proper way. I've done little more than simple tests however, and nothing close to being usable. There are some ways so far off in the original TIGER data that geo-matching would fail to locate the right way. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
* Alan Mintz alan_mintz+...@earthlink.net [2012-07-29 18:54 -0700]: [1] When combining ways in JOSM (at least), values for tiger:* tags are combined with : (colon) as a delimiter, instead of ; (semi-colon). Why, and should this be changed? I believe this behavior was intended to make tiger:tlid merging work a little better. As I understand it, the TIGER data originally imported was structured so that a single road was composed of many segments connected end-to-end. For the import, all segments with the same data values were concatenated into a single way and the IDs of each constituent segment were concatenated, separated by colons, and stored in the tiger:tlid tag. Thus, when combining two TIGER ways, using a colon to join their tiger:tlid tags would give a roughly correct reflection of the mapping between TIGER data and OSM data. I don't know why the decision was made to apply that to all tiger: namespace tags rather than just the tiger:tlid tag. Obviously, this doesn't help with way splits; the tiger:tlid value gets copied to each half, even though the original segments are now divided across the two ways. On top of that, TIGER doesn't use the segment structuring anymore; their data is more like OSM now, and each road gets a feature ID that's unrelated to the old TLIDs (though there might be a table somewhere providing a correlation between the two systems). Given all that[0], it seems reasonable to drop tiger:tlid on edits like the created_by tag. [0] Plus my personal experience that I periodically have to delete tiger:tlid tags after merging ways because the resulting tag value exceeds OSM's length limit. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NYC administrative boundaries and Nominatim
On Mon, Jul 30, 2012 at 5:11 AM, Kevin Kenny kken...@nycap.rr.com wrote: On 07/29/2012 11:56 PM, Skye Book wrote: Do we have a source for NYC administrative boundaries? http://www.nyc.gov/html/dcp/html/bytes/districtsmetadata.shtml I'm not sure of the license situation with any of the NYC.gov datasets. I've gotten different answers from different people I've talked to. Some people in some offices say that it's fine as long as we take certain steps, others say it's not, and others have different views altogether. I'm working to get some authoritative data on this. While I'm generally not a big fan of imports, administrative boundries are hard to do in another way, and as Richard Welty points out, it's generally a good thing to replace these nodes with true polygons, and then we can also use data sources to fill in population tags. And what are boroughs in terms of place? I'm thinking county- though that's not right. Certainly the populations should be added. The boroughs of New York are counties; confusingly, the borough names and the (coterminous) county names don't always match: BoroughCounty The Bronx Bronx County Manhattan New York County Staten Island Richmond County Brooklyn Kings County Queens Queens County Indeed that is confusing. Off the top of my head, I see two simple solutions: 1. We tag the areas as counties, but use the common names as the primary name, and these official names as alt_name. 2. We create a new administrative relation that has the same geometry as the county. I would lean towards the first, as it means less data and more clarification. Thoughts? - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
10, Park Plaza, Central Square, Bay Village, Middlesex, Massachusetts, 02116, United States of America. http://nominatim.openstreetmap.org/details.php?place_id=21777524 The Central Square, Bay Village and Middlesex are what are confusing me as they look to be points and I'm not sure what the deal is with poi points vs admin polygons. And why Boston the city doesn't come up. I have seen 'hillsborough county' show up many times for queries around me (west/central middlesex in ma; hillsborough is in nh). I have not yet figured out if this is a data problem in osm or bugs in nominatim, or nominatim having well-meaning heuristics to find points when ideally there would be boundary polygons. pgpzwKHJZnTle.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
On Mon, Jul 30, 2012 at 8:25 AM, Metcalf, Calvin (DOT) calvin.metc...@state.ma.us wrote: So I'm somewhat confused about how nominatim actually works. A good example is the building I work in (10 park plaza Boston ma) the version of nominitum on the website gets the correct location on the first try (note mapquest has it as the 3rd result) but they have it as being Often what happens is that you have one of two problems, in this order: 1. Nodes 2. Incorrectly prominent areas Nodes are a major problem. In the case of a node area, Nominatim will attempt to guess at how large/prominent the area is. If it's a city, for example, it will be very lose about how far out it thinks the city borders are. Neighborhoods, same thing, and so you get these odd classifications. The solution to this is to replace nodes with polygons, period. Often related is the fact that these nodes are often labeled incorrectly, or the area nearby is. That's why much of Washington, DC is considered part of Fairfax, VA, because Fairfax is a node, and a city. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
Metcalf, Calvin (DOT) calvin.metc...@state.ma.us writes: So basically if we see nodes like that, get rid of them? No, I think it's: If there's a node for the place, it's progress to replace it with a polygon. Not Just delete place nodes pgpaHaOu9jRqT.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
*constructively get rid of them For places that already have boundary relations (like Middlesex county) what is the best method to do that -Original Message- From: Greg Troxel [mailto:g...@ir.bbn.com] Sent: Monday, July 30, 2012 2:57 PM To: Metcalf, Calvin Cc: 'Serge Wroclawski'; talk-us@openstreetmap.org Subject: Re: [Talk-us] administrative boundaries and Nominatim Metcalf, Calvin (DOT) calvin.metc...@state.ma.us writes: So basically if we see nodes like that, get rid of them? No, I think it's: If there's a node for the place, it's progress to replace it with a polygon. Not Just delete place nodes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
On Mon, Jul 30, 2012 at 2:57 PM, Greg Troxel g...@ir.bbn.com wrote: Metcalf, Calvin (DOT) calvin.metc...@state.ma.us writes: So basically if we see nodes like that, get rid of them? No, I think it's: If there's a node for the place, it's progress to replace it with a polygon. Correct. The answer is If you see bad data, replace it with good data. It's also useful to think of Nominatim as a data product, like a rendering. Some things are due to bad rendering and some things are due to bad data. One of the things that's nice about Nominatim is that it gives you that detail page where it explains how it derives its answers. That gives you the opportunity to fix the data, and if it comes to it, send useful feedback to the Nominatim developers. I realize my email in the other thread could come off as complaining about Nominatim- I'm not. I'm mostly complaining about the poor data quality of New York City in OpenStreetMap in hopes that we'll be able to address it. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] administrative boundaries and Nominatim
So I transferred the attributes from the middlesex node to the relation and deleted the node, lets see how this works. If I was to complain about one thing nominatim related it would be the documentation. While I was able to find some pretty detailed info for installing it, but less about how it worked. -Original Message- From: Serge Wroclawski [mailto:emac...@gmail.com] Sent: Monday, July 30, 2012 3:17 PM To: Greg Troxel Cc: Metcalf, Calvin; talk-us@openstreetmap.org Subject: Re: [Talk-us] administrative boundaries and Nominatim On Mon, Jul 30, 2012 at 2:57 PM, Greg Troxel g...@ir.bbn.com wrote: Metcalf, Calvin (DOT) calvin.metc...@state.ma.us writes: So basically if we see nodes like that, get rid of them? No, I think it's: If there's a node for the place, it's progress to replace it with a polygon. Correct. The answer is If you see bad data, replace it with good data. It's also useful to think of Nominatim as a data product, like a rendering. Some things are due to bad rendering and some things are due to bad data. One of the things that's nice about Nominatim is that it gives you that detail page where it explains how it derives its answers. That gives you the opportunity to fix the data, and if it comes to it, send useful feedback to the Nominatim developers. I realize my email in the other thread could come off as complaining about Nominatim- I'm not. I'm mostly complaining about the poor data quality of New York City in OpenStreetMap in hopes that we'll be able to address it. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
great idea, have done it manually from time to time when I edit tiger data. just adding my support after reading pro/con for certain tags. Ideally you can come up with a default list and users can extend it. On Sat, Jul 28, 2012 at 12:33 AM, Toby Murray toby.mur...@gmail.com wrote: Some people may not even be aware of this but JOSM silently discards the created_by tag if it exists on any object you change and upload to the API. This tag was deemed unnecessary and counterproductive a long time ago and this is just a way of cleaning it out of the database as people edit. Not sure if Potlatch does anything like this. What do you think about adding a couple of TIGER tags to be silently dropped? As more attributes get added to things in OSM the tag list can get kind of big and annoying to look through, especially when some of them are of no real value. Specifically, I try to always do a modified search in JOSM before I upload and remove the tiger:separated and tiger:upload_uuid tags from things I have touched. I believe the tiger:separated tag was set on all residential or higher roads. 98.6% of the values are no and most of them are on minor streets where it is not really an interesting value. On the remaining roads it seems, in my experience, to be wrong a majority of the time anyway. So I see no value in this tag. I believe Dave Hansen said the UUID tag was useful during the TIGER import process to verify things and fix problems but I see no value in it now. It is such a large value that it takes up about 1 GB of space in the (uncompressed XML) planet file according to my calculations. As stated above, this would only delete the tags on objects that you have already modified in some way, not on everything you download. Are there any other tags that people feel should be automatically discarded? tiger:tlid and tiger:county seem mildly useful. What about tiger:cfcc and tiger:source? I don't currently remove those from my changesets but don't really see too much use for them either. Not really sure about the zip code tags. They seem like they could be useful but I am not aware of anything that actually uses them. If there is agreement, I will submit a patch to the JOSM devs and reference this thread. Toby ___ 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] New York Times Article Mentions OSM
For those who may not have seen this: http://www.nytimes.com/2011/03/28/business/28map.html?_r=3 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
