NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

Hello! I am trying to load a PBF dump of Russia into a PostgreSQL database using osm2pgsql. All works almost nice, but planet_osm_polygon table does not contain rows corresponding to objects situated in partly Eastern, partly Western Hemisphere, such as Chukotka Autonomous Okrug, Far Eastern Federal District and Russia itself. I checked this fact with the following query:

select * from planet_osm_polygon where boundary='administrative' and (admin_level='2' or admin_level='3' or admin_level='4') order by admin_level

All regions have been created successfully, but those 3 are absent. Here is my command for osm2pgsql to create the database:

osm2pgsql --create --database geo3 --slim -U postgres -E 4326 --style --hstore --multi-geometry -C 20000 --number-processes 2 -r pbf ru.osm.pbf

Could anyone please help me?

asked 10 Jan '19, 09:32

molokanov's gravatar image

accept rate: 0%

edited 11 Jan '19, 11:51

SimonPoole's gravatar image

SimonPoole ♦

It isn't possible to represent objects crossing the dateline in WGS84 coordinates and OSM data does not contain any such objects (obvously).

All objects that "should" cross the dateline have been split. I would suggest turning on the data layer on and inspecting some of the objects near the dateline.

permanent link

answered 11 Jan '19, 00:45

SimonPoole's gravatar image

SimonPoole ♦
accept rate: 18%

edited 11 Jan '19, 00:48

I understand the fact that in WGS84 these objects are split by 180th meridian into two or more separate parts, some of them starting from 180W and other ending at 180E. Consider, for example, relation id 151231. OSM provides all necessary "vertical" ways along 180E and 180W longitudes that are members of this relation and which are performing this splitting and closing all resulting polygons. Apparently, a set of closed polygons can be used to create geometries for the whole relation and we can see this set of polygons if we simply request the relation in the browser: But my osm2pgsql doesn't build its geometry. How should I make osm2pgsql build it?

(11 Jan '19, 05:39) molokanov

I just checked my database, I have six entries in planet_osm_polygon for 151231 which looks about right.

You are looking for the negative id I hope?

As in

select osm_id from planet_osm_polygon where osm_id=-151231;
(11 Jan '19, 06:33) SimonPoole ♦

Exactly. I'm looking for osm_id=-151231 with the same query but, on the contrast, I have no entries. What can be the cause?

(11 Jan '19, 07:58) molokanov

osm2pgsql version? And are the polygons in question unbroken in your input data? (I know that is difficult to determine)

(11 Jan '19, 08:18) SimonPoole ♦

osm2pgsql 0.96.0

To determine whether all polygons being formed with osm2pgsql are unbroken seems to be impossible. They are not saved in any database field. And members of the relation are ways which are obviously unclosed.

Instead, I did the following thing. I took the latest OSM dump for Russia, loaded it into PostgreSQL, the result is the same. I took all members of relation 151231 via downloadable XML file of the relation. Among the ways listed there, some of them are absent in planet_osm_line table. For example, 180th-meridian ways 239992373, 23820613 and especially border way 50752242. Does it necessarily mean that I have some polygons created by osm2pgsql unclosed?

(11 Jan '19, 08:54) molokanov

Right now the suspicion is that there might be an issue with geometry building that crept in between 0.95 and 0.96 (it does seem a bit unlikely though).

I would like to investigate a couple of things before continuing here.

(11 Jan '19, 09:46) SimonPoole ♦

Can you check if the relevant ways from the antimeridian are in your database?

For example way 239992380 (in planet_osm_line).

Sorry I didn't see that you had already answered this.

In any case the issue is likely that extracts from geofabrik do not contain the antimerdian ways and osm2pgsql then obviously can't build the polygons, I tested with an extract of Fiji and saw exactly this issue. My regular database contains the full planet and, naturally, doesn't have this issue.

I've raised the issue with geofabrik, lets see what Frederik says.

(11 Jan '19, 11:02) SimonPoole ♦

I have checked required ways. Way 239992380 is present in planet_osm_line, whereas way 239992373 is absent.

I will try to load bz2 dump, instead of pbf, maybe this will help me. Full planet is too huge for me, my workstation has 32 GB RAM.

(11 Jan '19, 11:47) molokanov

bz2 dump also didn't solve this issue. Results are the same. Hope we will get Geofabrik's answer soon.

(11 Jan '19, 13:19) molokanov

For reasons unknown, the Geofabrik polygon files used for clipping Aaia, Russia and the Far Eastern District did not extend to 180° but only to 179.9999° (and -179.999°). With regard to Fiji, the Australia-Oceania file did not even contain the over-the-dateline part of the nation, even though the Fiji polygon itself did. I've fixed these issues now and hope that tomorrow's extracts will be good.

(11 Jan '19, 14:33) Frederik Ramm ♦

I've checked the new extract for Russia. It is still not corrected. At least two ways with absolutely different tag sets are absent in the resulting database, but they both are needed to from the country's border correctly:

(14 Jan '19, 07:18) molokanov

Many years passed. And I faced the same problem. Just used osmosis to merge russia.pbf and us.pbf since the us extract borders the russian one. It's not necessary to download planet.pbf. It seems this kind of manipulations may help with other dateline issues.

(15 May '22, 17:54) shmeser
showing 5 of 12 show 7 more comments

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 10 Jan '19, 09:32

question was seen: 2,823 times

last updated: 15 May '22, 17:54

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum