I want to filter the national borders of the countries in Europe, thus admin_level=2. I composed the following query for OSMfilter (the chevrons allow to feed multiple lines into the Windows Command Prompt)

osmfilter ^
  --verbose ^
  "D:/GIS Data/Data/europe-latest.o5m" ^
  --keep-relations="boundary=administrative AND admin_level=2" ^
  --keep-nodes= ^
  --keep-ways= ^
  -o="D:/GIS Data/Tijdelijk/countrieseurope.osm"

When I convert/import this file (~ 970 MB) using either osm2pgsql or ogr2ogr, the countries are rendered correctly. But there are also al lot of boundaries from provinces and municipalities (admin_level > 2) rendered. The happens for instance in Spain, Portugal and Belgium; thousands of local boundaries are rendered. On the other hand for instance in The Netherlands, Slovenia and Norway only the national borders are rendered (which is correct).

It seems to me both osm2pgsql and ogr2ogr are rendering the OSM file correctly (checked the OSM file manually). So the data of the unwanted local boundaries have to be in the OSM file extracted with OSMfilter. Then I executed the following query:

osmfilter ^
  --verbose ^
  "D:/GIS Data/Data/europe-latest.o5m" ^
  --keep-relations="boundary=administrative AND admin_level=2" ^
  --ignore-dependencies ^
  -o="D:/GIS Data/Tijdelijk/countrieseuroperelation.osm"

This yields an OSM file with relations of the national borders of about 60 countries, which is correct. So it seems to me the unwanted data is filtered when OSMfilter is resolving the child relations, ways and nodes of these 60 relations. Why is this unwanted data included by OSM filter? Should I change my query? Or is perhaps the data insufficiently tagged in some countries (as the problem only occurs in about half of the countries).

BTW: This question is related to my question about Osmosis. I tried to do the same query in Osmosis to see if the dependencies on the 60 relations are resolved in another fashion by Osmosis.

asked 05 Feb '16, 03:38

Steijn's gravatar image

Steijn
61569
accept rate: 0%

edited 05 Feb '16, 03:40

You know you can download the boundaries from https://wambachers-osm.website/boundaries/ ?

(05 Feb '16, 07:43) escada

I already filtered the correct data with QGIS. ;) However, I want to know why osmfilter returns so much data not related to the admin_level=2 boundaries. This way I hope to learn more about OSMfilter.

(05 Feb '16, 11:41) Steijn

Another update:

I got Osmosis working in the correct fashion (for the solution see: https://help.openstreetmap.org/questions/47931/filters-in-osmosis-filtering-administrative-boundaries ), so now I can compare the results of Osmosis to the results from OSMfilter.

I downloaded the Geofabrik file of Portugal as Portugal got improperly filtered by OSMfilter (see above). I filtered for boundaries=administrative AND admin_level=2.

OSMfilter:

osmfilter ^
  --verbose ^
  "D:/GIS Data/Tijdelijk/portugal-latest.o5m" ^
  --keep-relations="boundary=administrative AND admin_level=2" ^
  --keep-ways= ^
  --keep-nodes= ^
  -o="D:/GIS Data/Tijdelijk/portugaladmin2osmfilter.o5m"

Osmosis (3 separate steps):

osmosis ^
  --read-pbf-fast workers=2 "D:/GIS Data/Tijdelijk/portugal-latest.osm.pbf" ^
  --tf accept-relations boundary=administrative ^
  --tf accept-relations admin_level=2 ^
  --write-pbf file="D:/GIS Data/Tijdelijk/step1.osm.pbf"

osmosis ^
  --read-pbf-fast workers=2 "D:/GIS Data/Tijdelijk/step1.osm.pbf" ^
  --used-way ^
  --write-pbf file="D:/GIS Data/Tijdelijk/step2.osm.pbf"

osmosis ^
  --read-pbf-fast workers=2 "D:/GIS Data/Tijdelijk/step2.osm.pbf" ^
  --used-node ^
  --write-pbf file="D:/GIS Data/Tijdelijk/step3.osm.pbf"

Using Osmosis the problem is gone! Osmosis correctly resolves the necessary child-ways and child-nodes for rendering the relations with boundaries=administrative AND admin_level=2, while OSMfilter also resolves parent-relations of child-ways and parent-ways of child-nodes, leading to much unnecessary data being selected. This becomes evident when comparing the file sizes.

File sizes:

  • Osmosis method (OSM file format): 1536 kB
  • Osmfilter method (OSM file format): 61568 kB

BTW: Any ideas to improve the rather tedious Osmosis method I used? :)

permanent link

answered 06 Feb '16, 01:11

Steijn's gravatar image

Steijn
61569
accept rate: 0%

edited 06 Feb '16, 01:18

I think it is probably a result of shared boundary ways that are included in the relations, like

http://www.openstreetmap.org/way/362763546

Which is a member of Spain, Portugal and several lesser boundaries.

Edit: Actually, it sounds like this is the issue:

http://wiki.openstreetmap.org/wiki/Talk:Osmfilter#Drop_specific_dependencies

There are relations included as members of the Spain relation.

If I understand correctly, osmfilter does not do what I speculated above, it resolves subordinate dependencies only, it doesn't seek out parents of included objects.

permanent link

answered 05 Feb '16, 13:11

maxerickson's gravatar image

maxerickson
10.8k1073151
accept rate: 30%

edited 05 Feb '16, 15:19

Sounds logic to me. So osmfilter also resolves all parent relations that use a certain way as a child, rather than resolving only the child-relations, child-ways and child-nodes of those relations containing an admin_level=2 tag. This cascades in resolving all parent-relations/ways in Spain and Portugal. So as I understand it, a solution would be to prevent osmfilter from resolving parent-relations/ways. Is this possible in osmfilter (or Osmosis?).

(05 Feb '16, 13:26) Steijn
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×211
×43
×2

question asked: 05 Feb '16, 03:38

question was seen: 5,329 times

last updated: 05 Jul '17, 08:16

powered by OSQA