On Tue, Jan 8, 2013 at 1:43 AM, Michael Patrick <[email protected]> wrote: > >> So there too, is a potential win for OSM. We could rely on current, highly >> accurate public domain boundry data and use that for rendering, geolocation >> and other places, while keeping it out of the OSM dataset. > > Please expand on this.
Okay. > There are already communities around Disaster Relief, > etc., and good etiquette would dictate that I wouldn't go in and edit their > data. You wouldn't go in and edit OSM disaster relief data? Why not? If I had local knowledge of data in OSM that was of higher quality or newer than what I found, I'd go in and fix it. I think HOT would want that. If any other disaster group using OSM felt that this was inappropriate, then they don't understand OSM. > Conceptually, there is already a convention in place for a separate > user account for a mass import, would it really be too much of a stretch > that there be a separate access for changing that data ( for instance > boundaries)? We don't have these kinds of access controls. We why would we want to? If a group needs static data, then they can use their own data with OSM as a separate layer. > Also, there are warning bells in Potlatch when I deleted a > duplicate object - if the object concerned was one of these boundaries, > maybe something similar occurs, if not a full stop? There are only two possibilities here: 1. You could have something to add to the data 2. You can't have something to add to the data In the first case, the editor shouldn't be stopping you. In the second case, then the data doesn't belong in OSM. > Just at the Federal Level, they have already dumped > 400,000 geospatial > datasets, and many states and counties are following suit with Open Data > initiatives. Of course tree bettles and stuff aren't candidates for the OSM > cartography, but some of those will enhance the end map for OSM (and > derivative projects) users. Some may, some may not. And some (like boundaries) are useful on the map, but not in the OSM dataset. - Serge _______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
