I have been thinking about this lately as well. In particular
city/county boundaries. I realize this is specific to the US but the
way a lot of our boundaries were imported from TIGER data makes them
very prone to well meaning but ultimately bad edits by mappers.
Basically, there is ALWAYS a node whenever one TIGER feature crosses
another, regardless of what kind of feature it is. This leads to
duplicate nodes sitting on top of each other which the various
validators complain about. So people tend to merge them to appease the
validator which is often not the right thing to do. For example, I've
been working in the Kansas City area a lot, expanding roads to dual
carriageways. When a boundary is merged with a road and I move the
carriageway, the boundary is now wrong and must be un-merged and
re-centered between the carriageways.
I have also seen another local mapper trying to do weird things with
the city boundary that ended up breaking things. While I don't think
boundary data should somehow be untouchable by some mappers I do think
that most of the time when new mappers touch a boundary, they do it by
mistake and introduce errors.
When I am doing normal editing I usually have a JOSM filter enabled to
hide boundaries because I don't care/know/want to touch them. What
about making such a filter default in the popular editors? If someone
WANTS to edit a boundary, they can disable the filter. Otherwise it is
read-only for normal editing. This is kind of a hack to implement a
"layers" concept from traditional GIS applications but it would be
easy to do.
Toby
On Sun, Mar 6, 2011 at 12:38 PM, Frederik Ramm wrote:
> Hi,
>
> Fabio Alessandro Locati wrote:
>>
>> Have you considered that the goal of OSM is creating a free (as
>> speach) map of the whole world... I think your view is not so close to
>> the project goal..
>
> It is certainly not the project goal to import every last scrap of free data
> no matter how irrelevant it is to editors. I think Russ is right; although
> I'd like to think maybe we don't need a "ClosedStreetMap.org" but just an
> easier way for people to add stuf from third-party sources to the maps they
> produce.
>
> (The name ClosedStreetMap probably tripped you, Fabio; Russ didn't mean
> closed data, he meant data that is open but doesn't make sense to edit in
> OSM. And by almost any definition, data that cannot sensibly be edited by
> OSMers should not be in OSM.)
>
> Bye
> Frederik
>
>>
>> 2011/3/6, Russ Nelson :
>>>
>>> Peter Budny writes:
>>> > I find this discussion very distasteful.
>>>
>>> That's because nobody is talking about the REAL
>>> solution. OpenStreetMap is the place for user-edited volunteered
>>> geographic information. It's NOT the place for importing information
>>> which would be nonsensical if a user edited it.
>>>
>>> The REAL solution is to have a ClosedStreetMap.org, which publishes
>>> data in the same format under the same license using the same tag set
>>> using the same API as OpenStreetMap, only it publishes read-only data.
>>> Some of the imports that I've done (NYC bike racks, NYS DEC lands, and
>>> NYS State Parks, which I'm currently working on), the data is
>>> maintained elsewhere. It useful to have for OpenStreetMap users, but
>>> not for OpenStreetMap editors. Why? Because for at least the last two,
>>> the boundaries are off in the middle of sometimes very dense woods,
>>> are not necessarily marked by signs, if signs are present they are not
>>> authoritative, and the original source of the data is a legal
>>> description, and no hand editing can change that.
>>>
>>> So take all these data sets, and their transformative programs, create
>>> .osm files out of them, and throw them into a database. When you get
>>> updates, rebuild the database.
>>>
>>> There's a few problems with the idea, e.g. what if somebody adds
>>> something to OSM that's already in CSM? Or, what if the data, although
>>> published from an authoritative source, is dirty? How does OSM
>>> override data in CSM?
>>>
>>> But I think there are fewer problems than the current system of one
>>> person dumping in megabytes for which there is no practical means of
>>> updating with another import.
>>>
>>> --
>>> --my blog is at http://blog.russnelson.com
>>> Crynwr supports open source software
>>> 521 Pleasant Valley Rd. | +1 315-600-8815
>>> Potsdam, NY 13676-3213 | Sheepdog
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk
>>>
>>
>
> --
> Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
