Frankly speaking I felt uncomfortable that all OSM 3D and OSM 4D tags were supposed to be kept in the main OSM database. In my opinion OSM in its current state is a pure 2D map. My vision was to have a separate server to keep 3D and other stuff (e.g. a hundred years old maps).
That's why I was glad to read an annoucement from Frederik Ramm:
"JOSM Separate Data Store plugin + server released"
http://lists.openstreetmap.org/pipermai … 06099.html
Here how it works:
The idea in this project is to enable JOSM users to record additional
data with OSM objects, but that additional data lives in a different
repository. The driver, in this instance, was that the data to be
collected was unsuitable for public release due to privacy issues
(personal data like household income etc.), but there may be other uses,
for example if you want to record stuff that is too volatile or detailed
The separate data store has all information keyed against OSM object
IDs, i.e. it cannot record geometries - only additional tags.
The SDS plugin makes it possible to have JOSM query another data source
for additional data related to objects just downloaded from OSM. For
example, you download ways #15, #20, #25 from OSM, then the SDS plugin
will query a different server "do you have extra info pertaining to ways
#15, #20, #25?" and the server may or may not return extra info.
These extra tags are then brought into JOSM just like any other tags,
and they can be edited, styled, filtered, and validated normally.
On upload, the plugin will again separate the extra tags from normal OSM
tagging, and will upload extra tags to the separate server only. (This
is based on a tag name rule, i.e. tags that begin with a defined prefix
go to the separate server, and all else goes to OSM.)
Looking forward to your opinions.
Quit interesting, but I guess we should keep our currente (simple) plan right ahead But I will consider, how this might be used as extension for O3DM
It's an interesting plugin (I had somehow missed it until now), but I do not think that storing tags in an external database and linking them against an OSM object ID would work particularly well. It might lead, for example, to mappers removing data, e.g. when re-drawing a building outline, without being able to notice this.
But more generally, are some additional tags really an obstacle to editing a building for those not interested in 3D mapping? I wouldn't have considered this a major issue. If anything, the building part geometries may increase complexity somewhat, but the plugin apparently does not help with that.
I do not think that storing tags in an external database and linking them against an OSM object ID would work particularly well. It might lead, for example, to mappers removing data, e.g. when re-drawing a building outline, without being able to notice this.
The server shoud receive diffs from the main OSM database end remove those buidings that have been removed from the main OS database.
I don't thing that storing some of tags in different database solve any problems. But it definitely create new ones.
Much better idea is adding to editors/api some layers/filters which hide by default more complex tags.
Generally is the great idea: "keep it simple" of course great idea. And I like it.
I was in some standardization committees. And I know: it is terrible difficult to explain all participants all consequences of decisions in specific areas.
I try in next days to collect some pros and cons for the Idea of separate 3D map.