[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Maposmatic-dev] Re: [OSM-dev] Questions on Nominatim and administrative
[Maposmatic-dev] Re: [OSM-dev] Questions on Nominatim and administrative boundaries + osm2pgsql
Sun, 20 Dec 2009 11:56:29 +0000
On Sun, 2009-12-20 at 11:27 +0000, Jon Burgess wrote:
> On Sun, 2009-12-20 at 11:55 +0100, David MENTRE wrote:
> > Dear fellow OSM hackers,
> > We are working on improving MapOSMatic, especially for international
> > support.
> > We are using http://nominatim.openstreetmap.org to query OSM in a
> > human-friendly way, which, indeed, is a wonderful tool!
> > Now we would like to use its results to query our own copy of the DB
> > (created with osm2pgsql). We found a way to do this, but we are not
> > quite sure it's the "right way" (tm) to do it...
> > For example, we query Nominatim for "Paris". One of the results is an
> > administrative boundary limit (the one with osm_id 7444). For that
> > entry, we would like to query our OSM DB to determine its
> > administrative level.
> > If we do:
> > select * from planet_osm_line where osm_id=7444;
> > then we don't get anything.
> > However, when we do:
> > select * from planet_osm_line where osm_id=-7444;
> > then we get exactly what we need.
> > Is this the right way to do it? Can we assume that, when nominatim
> > returns an entry with class="boundary" type="administrative" and
> > osm_type="relation", then we can safely query the planet_osm_line
> > table with the _opposite_ of osm_id?
> The ways which make up the 7444 relation must have an error in them
> somewhere which prevents osm2pgsql from forming a polygon.
On closer inspection, the Paris boundary does form a complete closed
polygon and is stored in the _polygon table as well:
gis=> select osm_id,name,boundary,admin_level from planet_osm_polygon
where osm_id in (7444,-7444);
osm_id | name | boundary | admin_level
-7444 | Paris | administrative | 8
All boundaries which form a closed ring should have entries in the