My newly uploaded Relation 15648965 is not being located by Nominatim

General talk Tagging general discussion
1

I thought it might be because I have one very long way (a single straight line with just 2 nodes) over the ocean. But someone suggeted to me “Searching from the website is done by a component called Nominatim. It is programmed to only look at certain tags on certain objects. It is possible that it’s not picking up your boundary=geocaching relations. Also, as it is external to the core of OSM, its indexing can sometimes lag behind a little. Can I suggest you drop a question into the tagging mailing list?” I do have the tags type=boundary and boundary=geocaching. Could that be the problem?

2

I think that’s correct.

I’d suggest creating something like that outside OSM and doing whatever you want with it there.

3

well, I’ve seen other similar regions defined as boundary=statistical, so I know that’s possible. Think that if I change it to statistical, that should fix the issue?

4

No idea, but I certainly wouldn’t change an arbitrary relation to a “statistical boundary” if it is not one. Adding it in this way changes it for everyone and not just you.

Maybe take a step back and explain in a bit more detail what you’re trying to do?

2 Likes
5

This sort of object doesn’t belong in OpenStreetMap.

OSM is for ground-truthed information - i.e. things that exist, can be seen, and can be independently and consistently reported by people visiting that location.

We make an exception for governmental boundaries because of their sheer utility, but that doesn’t mean that any and all boundaries (or other geodata) are fair game for OSM. If we were to become a clearing house for every single type of geodata that exists in the world, we’d sink under a morass of unmaintainable data very very quickly.

If you want somewhere to host this data, you could try using https://umap.openstreetmap.fr/, which is a site where you can create your own collections of data (and which incidentally has an OSM map background).

3 Likes
6

relation that is mentioned here: Relation: ‪North Wales‬ (‪15648965‬) | OpenStreetMap

7

thanks for that information. I will look into that .fr site.

3 Likes
8

The tagging was not at all the issue that Nominatim doesn’t have the relation. The area is simply not closed.

That said, I notice that instead of deleting the relation, you are creating more relations that abuse the boundary=statistical tag: Relation: ‪Southern Scotland‬ (‪15659647‬) | OpenStreetMap Can I kindly ask you to stop that?

2 Likes
9

Not saying I agree with the tagging used by OP but what is the definition of a “statistical boundary”, to then say this isn’t one?

I can’t find anything on the Wiki to define it. I also had a look on the ONS website and couldn’t find anything relating to this.

Does anyone have a definition? (I’m happy to then create documentation for this value)

1 Like
10

how can I delete a relation ?

11

I just read something that said that if a relation is empty, OSm will automatically delete it. so I will try removing all the members of the four relations I created and upload. then I will pursue another way to create the polygons I want.

12

I deleted the relations, additionally restored the splitted segments to the previous state (before further misfortune happens due to improper deletion - I already had to correct a few mistakes in the past few days).

Best regards,
Mario

1 Like
13

The German Wikipedia has a statement on this:

At European Union level there are also NUTS:

Best regards,
Mario

3 Likes
14

Thanks!

For reference, I’m going off the Google Translate version of link 1 and the English Wiki version of link 2.

It looks like the German page describes the value as being a breakdown of a municipality (e.g. city) into smaller regions for the purposes of statistical reporting - which makes sense in terms of the value’s name.

The NUTS page looks to be for much larger areas than this (e.g. splitting up a country, rather than city) so wouldn’t be consistent with the current German definition.

We could take a wider definition of “splitting an administrative area into smaller regions for the purposes of statistical reporting”. Though I’m not really sure if this is the sort of thing we should be mapping in OSM.

15

I would be careful about defining a statistical area as a subarea of an administrative area. Apart from at higher levels (countries etc) they may well form an alternative hierarchy of polygons, “arbitrarily” crossing admin boundaries. It might be better to not refer to administrative areas but to leave it at something like “an area (officially) defined for statistical (reporting) purposes”

2 Likes
16

thanks. and I was trying to be so careful as to not change anything but simply to add those relations;

17

I think the “officially” is important here, as otherwise we’ll end up with all sorts of “ad-hoc” boundary definitions that describe vague areas that aren’t really verifiable.

1 Like
18

I agree, Verifiability is an important concept in OSM.

19

Thanks all. I have created the page boundary=statistical to help prevent confusion in the future.

As always, please feel free to improve!

2 Likes