The problem with lengthy blog posts is that they result in lengthy replies
and
probably a long thread :-)
I think most users never look at the edit history and most of us that
occasionally do look at it, do it mainly to get some idea about the
validity of
the data. To use our data to make historical maps, we have to finish making
the
current "snapshot" of the world first, then it might be possible to start
looking at a way of making different more or less linked snapshots in time.
I
agree it might not be easy, but I think that just because it is difficult
to
build a space shuttle, that should not stop us from trying to build the car
that
most of us actually need first.
The rendering performance problem for lower zoom levels, is probably better
handled during import/update. If apmon keeps improving the performance of
osm2pgsql, then it might be realistic to have a "normal" high zoom database
and
a separate low zoom database where only the tags need for low zoom levels
are
imported and the geometries are simplified (it might be as simple as using
ST_simplify, but I have no experience with that and currently no access to
capable hardware for testing). From Frederics SOTM slides it looks like the
sweet spot is around zoom level 8.
JOSM already handles different layers quite well including copy/cut/paste
and
basically just needs to keep track of the different data sources and have
an
option to "paste with reference". Other editors that don't want to bother
the
user with the complications of layers can have a combined view of the
layers and
silently add and/or change objects in the appropriate layers depending on
the
type. This of course requires that we split the main database into layers
by
tags.
If we split the layers by tags, the layer repository can be used to keep
track
of what layer a tag belongs to. That will take away a little of our freedom
to
tag anyway you like, by requiring that you register your new tag with the
repository first. We could use something like the Tag Central [1][2] idea
for
that and I don't think it would be such bad thing, if you were required to
document the tags you invent. It would also make it easier for other bird
watchers to discover that there is a bird migration layer and how to use
the
special tags for it.
The layer repository could also have an optional link to a tile server,
that you
can use as background, ex. you can work on the admin area layer without
having
to load the entire dataset for a country - I didn't try, but I expect JOSM
would
not handle loading the France or Germany extracts very well, if at all.
I do share Martins concerns about how to handle updates to linked data, but
maybe
that can be solved by having both hard and soft links, so the user that
creates
the link makes the decision. That will also force you to think about if
these
two areas are actually linked or did you just reuse the nodes that were
conveniently already there?
If you have both layers open, you could have a "also update soft links"
mode for
those that know what they are doing and in the historic layer we could keep
the
soft links in an "un-linked, but not yet completely destroyed" state, where
somebody can manually check if the link should be restored or removed.
That will not completely solve the problem with historic maps, but if that
is
the only issue, I don't think that should stop us.
@Lester: Did you try the merge layer feature in JOSM or did I misunderstand
your
problem?
[1] Video: http://vimeo.com/14776099
[2] Slides: http://www.frankieandshadow.com/sotm10/tagcentral.pdf
/Jais
On Mon, Sep 24, 2012 at 4:35 PM, Martin Koppenhoefer wrote:
> 2012/9/24 Jochen Topf :
> > http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html
> > If anybody wants to comment, I think this mailing list is the right
> place.
>
>
> IMHO there are different requirements for these layers according to
> what is on them and how it is related to the data on other layers.
>
> E.g. the birds routes would not create much problems because they are
> only roughly linked to current OSM-data, while for the historic data
> layer I think it would be desirable to have that directly linked (or
> at least a possibility to link it) to the current data. This is
> important when there are remains of the historic objects that are
> still (also partly) present in the current world. These could be
> either physical but also "conceptual" (e.g. parcels of a roman castrum
> which are still valid for todays town, leading the streets (=voids) to
> be where they used to be).
> Other examples for this might be city walls, ruins and other remains
> of historic buildings, historic walls, ...). The problem here is not
> with static data but arises from the fact that our current OSM data is
> in continuous motion: as soon as someone moves the current city wall
> (or refines it) in order to improve it, the historic-layer city-walls
> should also be refined (or they will get out of sync). We could maybe
> have someth
