On Mon, Jul 22, 2013 at 12:00 PM, the Old Topo Depot <[email protected]> wrote:
> The LWG has not seen this, as I was not aware of that requirement, and > assumed the Import US group provided comprehensive guidance. It's not a requirement except that I don't think any of us have the experience to read a license like that and understand it. Legal wording is a bit like code- thinking you can read it without a legal background is a mistake, and since there are lots of clauses, I'm wondering if someone with a legal background has taken a look at it. > If consensus is that building outlines are not > useful without addresses, please explicitly state that now to save time and > effort. Again, I am not proposing individually adding address points; this > proposal is for building outlines (and perhaps land use updates) only. It's my view that building outlines without addresses aren't worth it, but I'm not stuck in my ways, if someone has an argument of why they're useful, I'd like to hear it. I don't speak for everyone, either. > WRT to PA land use, those polys are already in the OSM DB, and many appear > rather rough. I think Paul removed a large amount of land use from California. > The city has a reasonable set of shapes, for example, there > are about 56 parks, and it seems useful to improve them where possible. If > the plan is to remove them from OSM across the board, I will drop the idea. Do the parks have names, or can we do some kind of conflation of park locations against landuse and come up with park outlines with names? > On the subject of including ids and future updates, the idea that ids are > not very useful appears to be in conflict with the notion of continuing > maintenance. The IDs are apparently persistent, and therefore are useful > for future update efforts. It's understandable that the two ideas appear in conflict, but they're not, and here's why: We need some kind of plan for update. One time imports, with no consideration made to maintenance is one of the biggest reasons that imports have such a bad reputation in OSM. If we're to fix that reputation, we need to address the issue head on. So then the question is "How do we do updates?" It's obviously very tempting to use the external dataset source_id's as a mechanism, but ultimately, the problem with that is, to put it bluntly "It doesn't work". It doesn't work for a few reasons. First, even if the data source uses consistent object IDs, you can't know for sure that an OSM user won't touch those object IDs on the OSM side. This is more than just a theoretical situation- when bot-mode was dealing with TIGER tags, I saw a lot of tiger tags which had been edited in some way or another. The end result is that the IDs from OSM are not a reliable source. The next problem is that you will invariably end up with data not from your import. A user will make a building trace, or a user will remove a building when it's demolished, etc. So your conflation process will need to handle these cases. And since you're now going to need to handle these cases of buildings w/o a building ID (using the geometry, or address, if available, then the question really is why do you need the building ID? There's a third problem with imported data with an external source tag, one that's hard to describe, but I've seen it very often... When an object in OSM has the feel of another dataset, users appear more hesitant to touch it. That means we lose out on mapper resources, and that's bad. So, if possible, we've been exploring ways to do the conflation task using information such as the geometry of the polygon, or address, or name, or some other information that would be the same whatever the source was. Jason put it really well once when he said (and I'm paraphrasing) "A good import is indistinguishable from normal mapping." Again, none of this is law or anything, but it's the result of a lot of thought by folks like myself, Paul, Ian, Jason, and others who have made imports, especially bad ones. - Serge _______________________________________________ Imports-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports-us
