Overpass API developpement

Text archives Help


Re: [overpass] Corrupted data in minutely updated DB


Chronological Thread 
  • From: "Neubauer, Sebastian" < >
  • To: " " < >
  • Subject: Re: [overpass] Corrupted data in minutely updated DB
  • Date: Fri, 6 Oct 2017 07:25:11 +0000
  • Accept-language: en-US, de-DE

Hi Roland,
thanks for your fast anwer!

Am 06.10.17, 07:06 schrieb
"
im Auftrag von Roland Olbricht"
<
im Auftrag von
>:

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




Archive powered by MHonArc 2.6.19+.

Top of page