Re: [Talk-us] Discardable TIGER tags
I was unaware of the TLID bug and the fact that TIGER has changed their data model although I kind of wondered about this because I didn't see a TLID attribute in the new TIGER shapefiles. I guess the new field is LINEARID? So yeah, that makes the tlid tag completely useless then. So, I think I'm going to submit a patch with the following tags: tiger:upload_uuid tiger:tlid tiger:source tiger:separated The one argument for keeping the separated tag was that tags with a "yes" value should be reviewed manually. But the tag will only be removed if the object is being edited which means that it may have actually been reviewed. And to me the signal to noise ratio on this tag just isn't worth it. Toby ___ 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 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
Re: [Talk-us] Discardable TIGER tags
* Alan Mintz [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] 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
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" 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] Discardable TIGER tags
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
Re: [Talk-us] Discardable TIGER tags
Hi, On Sun, Jul 29, 2012 at 7:54 PM, Alan Mintz wrote: > Some people have been removing some TIGER tags already for a while. My only > concern would be that, if all the TIGER tags are removed from an object, we > should add TIGER05 to the source tag, so as not to completely lose > attribution. The lineage would still be preserved in the feature's history. Going back to v1, you would always be able to see that the creator was DaveHansenTiger. Assuming that Dave never used that account to do anything but the TIGER import. I see some more recent changesets by that user that seem to be import fixes, like this one here. http://www.openstreetmap.org/browse/changeset/2443534 All in all though, I don't think we need that tag to preserve lineage. Changesets are the place to include lineage information, if you ask me. (I'd deprecate the source= tag altogether, but that's a different discussion) Martijn -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
At 2012-07-28 00:33, Toby Murray wrote: What do you think about adding a couple of TIGER tags to be silently dropped? ... tiger:separated tiger:upload_uuid +1 tiger:separated I never knew what it was supposed to mean. If it was (as its name suggests) to indicate a physical separation between roadways in each direction, it's almost never accurate for that purpose, IME. Even if it once was, that's probably the most commonly changed feature of a road, usually by building of raised planted center dividers.[0] UUID +1 tiger:tlid At one point, I tried to use TLID for something, only to discover that there was a bug in the import that ended up putting the wrong values on some ways. This was confirmed by Dave Hansen at the time I brought it up. Dump it. This brings up another issue[1]. tiger:county I'm not sure this has been maintained well. I've seen roads combined to cross county lines. People have worked hard on better county polygons, which we should use. Dump it. tiger:cfcc tiger:source +1 zip code Often inaccurate, and subject to the same lack of maintenance problem. I found it useful for a while to get me in the right area when consulting a zip-to-assessor's book lookup I created for San Bernardino County, but I have a better solution now. Dump it. Some people have been removing some TIGER tags already for a while. My only concern would be that, if all the TIGER tags are removed from an object, we should add TIGER05 to the source tag, so as not to completely lose attribution. [0] When micro-mapping planted raised medians and grass strips along sidewalks, what are the correct tags to use? They're not gardens, forests, or parks, though they have grass and trees. [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? -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On 29 July 2012 23:21, Toby Murray wrote: > On Sun, Jul 29, 2012 at 3:25 PM, Ian Dees wrote: >> >> While we're incrementing every single version number of TIGER data, we >> should think about expanding the road names, too. Using the prefix and >> suffix data already on the majority of the ways makes this pretty >> fool-proof, so where it makes sense I think we should do that, too. > > Please check your glasses and re-read my message :) I am absolutely > not proposing an automated edit. > > I have a working JOSM that automatically deletes tiger:upload_uuid. > The way I implemented it mirrors JOSM's concept of "uninteresting" > tags. This means that there is a default list of "discardable" tag > keys. The list can be modified in the advanced preferences. Search for > "tags.uninteresting" in the preferences if you want to see how it > works now. > > The question is just what goes in the default list that gets populated > the first time you fire up a new JOSM version with this feature. > > So far I have: > > tiger:upload_uuid - definite yes > > tiger:source - No opinions > > tiger:separated - mixed feelings. If I could just remove "no" values > there seems to be unanimous support but that would require doing it > differently, probably hardcoding it in the source instead of going off > of a user preference. Or extending this user preference's syntax, probably not much work. > > 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 have opposed removing tiger:tlid in the past but this tag is unlikely to be ever used in practice. This information could also be gathered from the history dumps even in case of way splits, they're easy to detect. (For people interested in dbpedia and linked data it's probably nice to see a direct external key of another database in a database but it's apparent that this data is not being maintained) Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sun, Jul 29, 2012 at 3:25 PM, Ian Dees wrote: > > While we're incrementing every single version number of TIGER data, we > should think about expanding the road names, too. Using the prefix and > suffix data already on the majority of the ways makes this pretty > fool-proof, so where it makes sense I think we should do that, too. Please check your glasses and re-read my message :) I am absolutely not proposing an automated edit. I have a working JOSM that automatically deletes tiger:upload_uuid. The way I implemented it mirrors JOSM's concept of "uninteresting" tags. This means that there is a default list of "discardable" tag keys. The list can be modified in the advanced preferences. Search for "tags.uninteresting" in the preferences if you want to see how it works now. The question is just what goes in the default list that gets populated the first time you fire up a new JOSM version with this feature. So far I have: tiger:upload_uuid - definite yes tiger:source - No opinions tiger:separated - mixed feelings. If I could just remove "no" values there seems to be unanimous support but that would require doing it differently, probably hardcoding it in the source instead of going off of a user preference. 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. tiger:county - I personally like this tag. Most states do have county borders but there are a few that are still missing. tiger:cfcc - seems like there is a reasonable argument for keeping it Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sat, Jul 28, 2012 at 2:33 AM, Toby Murray 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. While we're incrementing every single version number of TIGER data, we should think about expanding the road names, too. Using the prefix and suffix data already on the majority of the ways makes this pretty fool-proof, so where it makes sense I think we should do that, too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On 7/29/2012 2:23 PM, Anthony wrote: FWIW, I strongly support removing tiger:tlid. However, I remember having a disagreement with others in the past about this, so I didn't bring it up. I agree that tiger:tlid serves no purpose after a user edit and can be removed. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sun, Jul 29, 2012 at 1:21 PM, william skora wrote: > Tiger:tlid - Could be removed. I've had newbies ask me at mapping > parties what it means, I haven't been able to answer them. I haven't > seen any use for its inclusion at this point. FWIW, I strongly support removing tiger:tlid. However, I remember having a disagreement with others in the past about this, so I didn't bring it up. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Hi, Sorry to be late to chip in. I would keep CFCC. It's a good tag to have both to be able to generate statistics (how much of original TIGER class mapping remains intact?) as well as for reference; I find the CFCC classification is usually good - even if the mapping onto OSM k/v is sometimes unfortunate. In itself a reason to keep them, we may decide to bulk-retag based on cfcc in the future. Unlikely, but fathomable. The uuid can co as far as I am concerned. The tlid as well. County can be discarded under the assumption that we have nationwide county-or-equivalent boundaries (I actually don't know if that's the case, for Utah it looks complete). The zipcodes don't have an equivalent in OSM right now, and are useful for geocoding, so I'd say leave those untouched. The separated taga I have never found to be useful or reliable. My vote would be to remove those as well. Looking forward to a leaner planet! Martijn > PS I find it very annoying that replies don't go back to the list by default You should check your email client settings. Sometimes posters explicitly set a reply-to field though - in that case, your reply will go to the person's email directly. I always do reply-all when replying to lists. > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us > -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Personally, I think there should be a tag to differentiate between a one-way road and half of a divided road; yes, a human can look at the map and make that determination instantly, but a computer requires some advanced analysis. (I can imagine some extra-nice rendering could benefit from this information…) Though I don't think such a tag belongs in tiger: namespace, the presence of tiger:separated is a half-decent hint for now. On the other hand, tiger:separated=no can go. The only use case I can imagine for keeping tiger:cfcc is if one is frustrated at the inconsistent application of different highway values, and would rather render by CFCC instead. However, it would make a lot more sense just to render directly from the most recent TIGER data in that case. To conclude, tiger:cfcc can go. PS I find it very annoying that replies don't go back to the list by default ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Here's my 2 cents on the mentioned tiger tags, fwiw: tiger:cfcc - As I understand, its original purpose was to classify different highway types, but once the appropriate OSM tags [derived in part from this tag, and then also from whatever other sources, imagery, personal visit, etc] have been added to the way, this tag doesn't serve any purpose. See: http://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map#Roads If someone wants to see the history of the way, they can check the history with that tag. Also, in my experience the CFCC from 2007 were often incorrect, especially for highway=residential ways that should be marked highway=unclassified, tertiary, secondary, primary, or service. Tiger:separated - After reading tiger:separated=yes in the link above, doesn't that mean the way should be mapped in OSM as two separate ways ? If it's already mapped as 2 separate ways, then delete the tag. Tiger:tlid - Could be removed. I've had newbies ask me at mapping parties what it means, I haven't been able to answer them. I haven't seen any use for its inclusion at this point. tiger:upload_uuid: Could be removed. I haven't seen any use for its inclusion at this point, was useful in past, as Toby mentioned. -will ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Ok well so far I see no opposition to deleting tiger:upload_uuid. I might go ahead and work on some code for this. Other than that we have some votes for keeping tiger:county, tiger:zip and tiger:separated although I personally still have it in for tiger:separated :) Any thoughts on tiger:source? I'm not quite sure what the value represents so I'm still on the fence about it. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sat, Jul 28, 2012 at 3:54 PM, Toby Murray wrote: > On Sat, Jul 28, 2012 at 2:16 PM, Anthony wrote: >> I'm all for upload_uuid being removed automatically. As for >> tiger:separated, is it possible to remove the tag only if it's set to >> "no"? The 1.4% that are set to something else should probably be >> reviewed manually. > > Might be possible but not the way I was hoping to implement it to > match existing code. I'd say keep it, then. > Has anyone ever used a tiger:separated tag to > guide them to something that needs review? Yes. > I have found a few "yes" > values that were incorrect. The rest were pretty obviously dual > carriageway on aerial imagery and the tag didn't really help me... And > once it is mapped as dual carriageway in OSM the tag is misleading. > That way no longer needs to be marked as separated since it now has > two parallel ways representing it. I agree with removing ones that are marked incorrectly. I think it's harmful to remove ones that are marked correctly, though. And I don't see any way to automatically distinguish between the two. Anyway, that's my opinion. I think it's useful information. And the fact that it is sometimes incorrect is, in my opinion, a reason to keep it. I support removing tiger:uuid precisely because there is no definition of what the correct value should be. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
On Sat, Jul 28, 2012 at 2:16 PM, Anthony wrote: > I'm all for upload_uuid being removed automatically. As for > tiger:separated, is it possible to remove the tag only if it's set to > "no"? The 1.4% that are set to something else should probably be > reviewed manually. Might be possible but not the way I was hoping to implement it to match existing code. Has anyone ever used a tiger:separated tag to guide them to something that needs review? I have found a few "yes" values that were incorrect. The rest were pretty obviously dual carriageway on aerial imagery and the tag didn't really help me... And once it is mapped as dual carriageway in OSM the tag is misleading. That way no longer needs to be marked as separated since it now has two parallel ways representing it. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
I'm all for upload_uuid being removed automatically. As for tiger:separated, is it possible to remove the tag only if it's set to "no"? The 1.4% that are set to something else should probably be reviewed manually. On Sat, Jul 28, 2012 at 3:33 AM, Toby Murray 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
Re: [Talk-us] Discardable TIGER tags
On 7/28/2012 3:33 AM, Toby Murray wrote: Not really sure about the zip code tags. I find the county and zip code tags to be useful at times to tell me where I'm located when doing Mapdust cleanup. I could probably come up with some other way to find myself if they weren't there, but it's convenient. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
