[OSM-dev] Questions on Nominatim and administrative boundaries + osm2pgsql

Jon Burgess jburgess777 at googlemail.com
Sun Dec 20 11:56:29 GMT 2009


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
polygon table.

	Jon






More information about the dev mailing list