<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Am 06.01.2011 16:44, schrieb Simone Saviolo:
<blockquote
cite="mid:AANLkTinBLDpehXVr3o3ipN6h31J0AQc4ax8Jo__5gH7R@mail.gmail.com"
type="cite">2011/1/6 Steve Bennett <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:stevagewp@gmail.com">stevagewp@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
Putting in place a serious process for tag migration will be
difficult. I suggest that a first step will be definition of
an actual schema, with version number. For example, define an
actual list of several hundred tags, with semantics, that
correspond to "OSM core 1.0". Then, we could have votes on
changes to the schema, with advance notice given: "On November
1, 2011, the main database will be updated to OSM core 1.1.
Please have your editor and renderer patches ready for this
date."</div>
</blockquote>
<div><br>
</div>
<div>I would even go further. I would like to see such a schema
become a sort of "OSM certification", to be awarded to consumers
that fully support it. <br>
</div>
</blockquote>
What's the benefit of that?<br>
What beside of this - I fear, stupid - "certification" is the
benefit for a hiking map in supporting e.g. maxspeed of motorways as
part of the OSM core being the decision basis to get the
certification?<br>
<br>
To make a better example: Garmin AiO for Europe is getting too large
for many devices currently - so the core definition you propose
would require to include buildings in the map, no matter of their
size and the drawbacks of excluding most old devices by including
the building layer?<br>
<br>
An alternative to "this product supports OSM Core n.n completely" as
a (the?) requirement for the certification would be "this product
does not interpret attributes from OSM conflicting to the Core
definition". <br>
<br>
This for me fit's better, but nevertheless not completely, as it
does not prevent devices to support other variants as well probably
conflicting in parts.<br>
<br>
Additionally there would have to be an
organization/council/something to give the certification to the
application (in wide interpretation) developer/vendor.<br>
<br>
But: even that does not automatically lead to high quality of the
product: A map without legend is worse than a map with missing
housenumber display. A public bus information system without support
of railway is complete in it's self defined domain - but lacks of
the railway network and therefore does not support the complete core
(I guess).<br>
<br>
I thought about some kind of layered-extracts a while to get kind of
a stable, well defined architecture for application vendors:<br>
An API (not THE api) could export a "car routing layer", a "building
shape layer", a "footway layer" and so on.<br>
That could be an enhancement of the XAPI concept by shortcuts for
complex queries, too.<br>
It probably could provide a bridge of the wiki principle of OSM
including the free-to-invent-new-tags to the application requirement
of a as much as possible stable base for data updates.<br>
Last, but not least it could be one solution to define renames for
"deprecated" tag usages of some kind, e.g. new invented subtags.<br>
<br>
To use the tree example discussed a few month ago (a tree versus an
important or lone tree) the "tree" layer could be split after that
discussion to an "tree" layer and an "important tree" layer
considering the new subtags and only providing the trees explicitly
tagged as important.<br>
<br>
I'm neither sure yet if that's a good idea, nor do I know if it is
clear what I wanted to say - but well - everybody can ask me.<br>
<br>
regards<br>
Peter<br>
</body>
</html>