On 25.04.2011, at 12:40, Frederik Ramm wrote:
> Hi,
>
> Jaak Laineste wrote:
>> What about following approach:
>> a) ban external source imports to the main database
>> b) create new separate solution (layer, server, API, whatever fits) for all
>> the imports.
>
> I think that is the way forward. If your data has special requirements, then
> put it in a special database, not in OSM. Do not abuse OSM as a vehicle for
> non-crowdsourced (or even non-crowdsourcable) data.
So I see two approaches here:
a) centralized database - collect imports to one place, close enough to OSM. I
was thinking about this, and there are good practical reasons for it; similar
reasons why OSM itself is centralized. This does not mean that in 2011 this is
the only possible solution.
b) distributed database - each database (data collection) has own home, and
there is one common directory to find them. Google has this kind of system for
transit data: they define format what everyone has to use, create common
directory and everyone (at least Google itself) can collect data directly from
different agencies. Technically OSM itself could be distributed: e.g. each
country keeps own coverage in own servers.
>
>> - planet.osm it would have the data in special section.
>
> No, planet.osm would not even know about that data. I imagine this to be
> something like in the brave new world of git: You can run a rendering server
> and you can instruct your osm2pgsql to pull data from the OSM planet
> repository, and from Alan's "US Borders" repository, and from someone else's
> "International Maritime Lights" database, etc.etc.; an expert editor could
> even allow you to do the same, pull data from different sources, even edit
> all of it if you have the proper credentials and upload back to all the
> different sources.
>
> There is of course still a case for many things to reside in OSM - e.g. it
> would not make much sense to have one database with major roads and one
> completely separate database with minor roads, as it would always be a
> terrible pain to extract from them a working, routable network. But
> especially where we're talking non-physical things like boundaries, such a
> de-coupling makes a lot of sense to me.
Radical separation could be used in some cases, but not in many others.
Specific sample: I have database with all building shapes of a 0.5-million
city. Number of shared nodes with roads is probably small, but OSM probably has
already some 1% of similar data (buildings). I also want to get contribution
from OSM community back to my database (otherwise it would be only giving). I'd
come out with following:
1. I'll create OSM API to my database.
2. I register my URL to the OSM meta-database (something remotely similar to
imports-table in wiki).
3. I'll integrate user authentication with OSM OAuth
4. If editor uses JOSM it first makes request "give data providers for bbox"
from OSM API, and then does HTTP requests to all of them.
5. In JOSM you see and can edit all the different sources (possibly with
different colors - in different JOSM layers). Special action there would be
"merge nodes on different layers", which would change node id of an external
database to the OSM node id, with this creates topological link between the
objects. Another special one would be creation of Relation with objects from
different sources.
6. If you save data, it can go to many different databases.
Data provider can also just create OSM files and give read-only http access to
them. But this would be very limited and would lead to manual copy of data to
OSM database, otherwise topological laundry could not be done.
What would be needed:
a) "OpenGeoMetaDatabase" - directory of OSM API-compatible data sources
(special discovery API). Initially with one source: OSM
b) support of OGMD in JOSM, osm2plsql and other tools - should be quite easy.
c) some reference cases where data provider would be ready to actually provide
live OSM API. Simplest case: set up rails_port with full OSM data structure,
then use same import procedure as you would with OSM. In real life you'd like
to have live API on top of your legacy geodatabase, which means many
months/years projects. Luckily there are some common GIS engines (ESRI, Oracle
Spatial etc) what they probably have.
d) probably some additions are still needed in OSM API too. Sample case that
you save relation which has non-OSM objects to OSM database - you must be able
to refer to external object IDs. Maybe object ID (osmid) should have more
generalized format (e.g. "corinefr-12343212").
Then organizational question: could it be part of OSM (as Meta-OSM), or
something external and independent? I'd prefer the first option, but some (like
Frederik) would like to keep well apart from the core OSM?
BR,
Jaak
_______________________________________________
Imports mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/imports
