<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 24.08.2011, at 19:57, Bryce Nesbitt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#ffffff" text="#000000">
    <br>
    <blockquote cite="mid:4E55285D.7070704@obviously.com" type="cite">On
      08/18/2011 03:23 AM, Jaak Laineste wrote:<br>
      See <a href="http://wiki.openstreetmap.org/wiki/OpenMetaMap">http://wiki.openstreetmap.org/wiki/OpenMetaMap</a><br>
    </blockquote>
     <br>
    When I look at statement "I put my dataset online using OpenMetaMap
    API" I immediately react "why invent a new standard?".  The linkable
    datasets could have a variety of APIs drawn from existing standards
    (e.g. shapefiles, kml, web feature servers (WFS)).  You'll get a
    more robust system if you leverage an existing feed rather than
    requiring data providers to invent one just for osm.<br></div></blockquote><div><br></div><div>Only new API would be for Links. For data existing standards would be reused - first of all OSM API, but I hope also WFS, ShapeFiles, Inspire etc can be used. The problem with both WFS and Shapefiles is that they have really basic GIS data model - no topology, no relations, no history/object versions etc. It requires more study and pilots to validate API suitability.</div><div><br></div><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">The proposal needs to address the end-user editing experience.  When
    user sees a feature on a map that is "wrong", how do they identify
    where the data came from, and understand the chain of actions needed
    to apply a correction?  You're talking about rather major additions
    to every single osm editing tool.<br></div></blockquote><div><br></div><div>Most of the needed concepts are already present in current editing tools: conflict resolutions, validators, relations, layers. External Links would be handled similarly to Relations, and data would be shown as separate Layer in JSOM.  It does not look so alien to me.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">I see the huge advantage of this approach is the licensing.  As you
    write "<i>OSM would not become derivate from any external databases,
      only the rendering would be</i>".  There are many many good
    datasets that are free to use, but not compatible with OSM's
    licenses.<br>
  </div></blockquote><br></div><div>Same actually for also non-free good datasets. But I'm not too optimistic really here, as for rendering and publishing combined map with OSM you still need to create derivate for OSM with all the OSM license implications. The licensing issue will be postponed - now you have to be clean before importing to OSM, with metamaps you have to worry later, when you actually load OSM and other database and put it together in your computer.</div><div><br></div><div><br></div><div>Jaak</div><br></body></html>