Corrupted data in minutely updated DB

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Corrupted data in minutely updated DB

sebastian.neubauer
Hi,
we have a minutely updated overpass database running since over a year
(v0.7.53).

All of a sudden, there are strange things, e.g. a lookup "is_in" of the
location lat: 49.75, lon: 10.17 Kitzingen in germany returns that it now lies
in Tunesia TN-83.

I have found nothing in the logs that helped me any further, is that something
that can happen in the minutely update? E.g. some corrupted updates..

If yes, is there a easy way to identify or even "repair" this state?

Or is the only way to throw everything away and start from scratch?

Sorry for the noob questions, but I never worked with the overpass server and
now I need to fix it ;-)

Any help appreciated and thanks in advance!

Best regards,
Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted data in minutely updated DB

Roland Olbricht
Hi,

> All of a sudden, there are strange things, e.g. a lookup "is_in" of the
> location lat: 49.75, lon: 10.17 Kitzingen in germany returns that it now lies
> in Tunesia TN-83.

Please figure out the id of the offending object and compare it to the
object on the main database.

I assume that

   is_in(49.75,10.17);
   out;

delivers for you, amongst others, an area

   area id="3601434953"

with tag "ISO3166-2"="TN-83". Such an area is always computed from an
OSM object. You can figure that out by

   is_in(49.75,10.17);
   rel(pivot);
   out;

In this cause it should be relation 1434953. Please check that relation
both on the main instance and your local instance:

   rel(1434953);
   out geom;

Are the results equal or different?

Best regards,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted data in minutely updated DB

sebastian.neubauer
Hi Roland,
thanks for your fast anwer!

Am 06.10.17, 07:06 schrieb "[hidden email] im Auftrag von Roland Olbricht" <[hidden email] im Auftrag von [hidden email]>:

    Hi,
   
    > All of a sudden, there are strange things, e.g. a lookup "is_in" of the
    > location lat: 49.75, lon: 10.17 Kitzingen in germany returns that it now lies
    > in Tunesia TN-83.
   
    Please figure out the id of the offending object and compare it to the
    object on the main database.
   
    I assume that
   
       is_in(49.75,10.17);
       out;
   
    delivers for you, amongst others, an area
   
       area id="3601434953"
   
Until here everything is exactly like you said, “3601434953” is in the result among other, e.g. "3602060182" "LY-NL", "3600192758" “LY”, "3600192757" “TN” and the correct Bavaria/Germany objects.

    with tag "ISO3166-2"="TN-83". Such an area is always computed from an
    OSM object. You can figure that out by
   
       is_in(49.75,10.17);
       rel(pivot);
       out;

Overpass turbo complained  “This query returned no nodes”, but it anyhow returned something.
But in this result I cannot find Tunesia, but also (only e.g. Dhehiba with the id 7167457)

    In this cause it should be relation 1434953. Please check that relation
    both on the main instance and your local instance:
   
       rel(1434953);
       out geom;
   
    Are the results equal or different?

I checked 7167457 and 1434953, both are equal as far as I can see.

A colleague gave me a hint, that maybe there is something with the area creation going wrong. I googled and found that I can “reset” this by stopping the area dispatcher, deleting “all area files” and then start the dispatcher again…Is that something I can try? What exactly are “all area files”?

Thanks,
Sebastian

mmd
Reply | Threaded
Open this post in threaded view
|

Re: Corrupted data in minutely updated DB

mmd
Am 06.10.2017 um 09:25 schrieb Neubauer, Sebastian:

>
> A colleague gave me a hint, that maybe there is something with the area creation going wrong. I googled and found that I can “reset” this by stopping the area dispatcher, deleting “all area files” and then start the dispatcher again…Is that something I can try? What exactly are “all area files”?
>

You can give it a try. Here's a list of all area files, they start with
area*

/srv/osm3s/db$ ls -l area*
-rw-rw-r-- overpass 3695247360 Okt  7 08:38 area_blocks.bin
-rw-rw-r-- overpass     134664 Okt  7 08:38 area_blocks.bin.idx
-rw-rw-r-- overpass  223084544 Okt  7 08:38 areas.bin
-rw-rw-r-- overpass       1528 Okt  7 08:38 areas.bin.idx
-rw-rw-r-- overpass 4577755136 Okt  7 08:38 area_tags_global.bin
-rw-rw-r-- overpass      67146 Okt  7 08:38 area_tags_global.bin.idx
-rw-rw-r-- overpass  868122624 Okt  7 08:38 area_tags_local.bin
-rw-rw-r-- overpass     176821 Okt  7 08:38 area_tags_local.bin.idx
-rw-rw-r-- overpass         23 Okt  7 08:38 area_version


--