Multiple WhosOnFirst-entries for Bremen (Germany). One is wrong!

[ghost]

Hello folks,

there are two whosonfirst entries for the German city Bremen:

Entry with type "locality": Wrong entry

Entry with type "localadmin": Correct entry

The first entry contains wrong information and therefore the Pelias engine returns wrong addresses. For example, the region is Lower Saxony, the county is Diepholz and the localadmin is Stuhr. This is wrong. In addition, the coordinates lbl, mps and nav are also wrong.

The other entry with type "localadmin" is correct. Can the duplicated (wrong) entry be deleted/changed promptly, as we use the Pelias engine for one of our business applications.

Best Regards tst-abat

[nvkelso]

The locality placetype is a core building block in Who's On First. It sounds like we should copy over the information from the localadmin to the locality and mark them as coterminous? What do you think @stepps00?

[stepps00]

Thanks for the report, @tst-abat

These issues all boil down to Who's On First maintaining an inaccurate centroid on the locality record. The fix here would be:

• Update the centroid geometries in the Bremen locality record
• re-PIP the locality + descendant records to fix the issues seen in Pelias
• Flag the localadmin and locality as coterminous (and verifying other placetypes are flagged as coterminous as needed, too)

This is a fairly straight-forward edit, we will try to patch this shortly through a PR.

[ghost]

Hello @stepps00,

thanks for the really quick implementation and correction of the data. That's great! I don't know if it's good practice to comment here again after closing an issue, but I have a question: For example, the hierarchy of the corrected entry still shows the following:

the country of Germany the continent of Europe the region of Lower Saxony the county of Diepholz the localadmin of Stuhr

What is the reason why this has not been changed? Because Bremen is a so-called city state and therefore the region (my interpretation is federal state) is actually also Bremen, not Lower Saxony. The openrouteservice we use, which in turn uses the Pelias engine, still returns this (wrong) result (see issue) Or is this a Pelias problem? I have already opened an issue there, but I don't have the feeling that it will quickly attract attention.

Sorry for my ignorance, maybe you can bring some clarity there.

Best regards tst-abat

[stepps00]

Hi @tst-abat, no problem. The issue you're seeing is that our Spelunker tool is not yet up to date with the most recent data changes. The hierarchy of this place in WOF now looks like this:

the country of Germany the continent of Europe the region of Bremen the county of Bremen the localadmin of Bremen

There are various property flags on each of these records, too, that Pelias uses to decorate address strings and search results. As soon as Pelias uses these data changes, you should see the correct results returned for Bremen.

[ghost]

Hello again,

thank you for your answers! Is it already foreseeable when the changes will be available? Spelunker is not up to date yet and under Geocode earth I don't see any difference yet either.

So it doesn't make sense yet to ask ORS to rebuild their Pelias index.

I also have another question: the information under wof:hierarchy seems to be correct. What is then the meaning of the following attributes?:

"qs:a1":"*Niedersachsen",
"qs:a1r":"0",
"qs:a2":"Diepholz",

Niedersachen is the german word for lower saxony.

Best regards

[nvkelso]

Hello @tst-abat. This data issue was fixed via https://github.com/whosonfirst-data/whosonfirst-data-admin-de/pull/46 a few days ago. That means the data in the Github repo now has the correct changes.

I'm not sure why Geocode.Earth might not incorporate this change yet. @orangejulius might you know?

As to the Spelunker it only receives occasional updates right now so it's expected to be out of date for some time.

The qs namespaced properties you reference are from an an antecedent project called Quattroshapes that collected open data from many national governments. That data project said that this feature's hierarchy (or parent administrative structure) included Diepholz and Niedersachsen because that's what the upstream data source said (there were not calculated fields). These fields are historic in Who's On First and not maintained and shouldn't be used for production applicaitons.

[ghost]

Dear @nvkelso and @stepps00,

thank you for your support. It is running again and ORS now finds the correct data for Bremen when searching for a specific address. If only Bremen is searched for, an entry for Lower Saxony is returned in addition to the correct entry. Also Geocode earth is not yet correct. But these two minor anomalies don't bother me. The main problem is now solved.

Thanks again and all the best. You are doing a great job!

Many greetings tst-abat