Rogier Wolff wrote: > > So, then, the recommendation should be that when extracting data, this > same procedure is followed, and if not, those ways should be marked > incomplete in a way that as much as possible doesn't interfere with > current tools. Making a node-id negative, which in other tools is used > a as a cheap "flag", therefore becomes a non-option. It also runs the > risk of those negative-ids becoming entered into a database, as > separate entities. > If possible I'd always provide complete ways, but it isn't simple using a stream approach such as that used in osmosis. A database is much more suited to this type of application and is something the osmosis pgsql schema tasks aim to solve.
If stream processing is used (ie. current --bounding-box task) I don't know whether chopping ways to fit the available node set or including full ways and breaking referential integrity is the best way forward. Both are easy to support and could be switched with a task option, the main question is which behaviour should be the default. > So a "key=value" pair like "incomplete=true" or "status=chopped" would > be my favorite. > I agree changing ids to negative is a bad idea. It does nothing to prevent uploads although is arguably better than modifying existing ones. My real issue with changing to negative is maintaining the referential integrity, it has to be changed everywhere it is referenced. I'd recommend against using a tag for this. The tag will only help if everybody always looks for it. The chances of everybody agreeing on a single tag and more importantly updating all tools to utilise it is fairly remote. I guess you could modify the api to look for the tag and reject it but ideally the api should remain tag agnostic, something osmosis has also managed to do up to this point. I still think setting a version id to 0 would be the best approach, it will forcefully stop a modified entity from being uploaded. Although I guess a tag could also be added if desired. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
