Re: [OSM-talk-be] RFC: removing OpenGeoDB and is_in tags (RFC by 29 Feb 2020)

[Midgard]

Quoting Midgard (2020-02-05 16:36:51)
> - tags with a "openGeoDB:" prefix and
> - "is_in" tags.
> 
> I hereby propose a mechanical edit to delete those from all features in 
> Belgium.

Done: https://www.openstreetmap.org/changeset/81642925

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] RFC: removing OpenGeoDB and is_in tags (RFC by 29 Feb 2020)

[Pieter Vander Vennet]

About the is_in: oh please, get rid of them.

About the geoDB: clean them up as well, although I am a bit more 
reserved. I don't know openGeoDB, but I feel that it is unmaintainted 
and superseded by the combination of OSM and Wikidata. I feel that using 
a wikidata entry is a more futureproof solution to this: the metadata 
about the place (such as population) can go on wikidata then.


In conclusion: go for it!

Mvg, Pieter

On 05.02.20 20:54, joost schouppe wrote:

I say "go"

Op wo 5 feb. 2020 16:37 schreef Midgard >:


Dear mappers

If you ever touched a place node, chances are you saw it was
cluttered with:
- tags with a "openGeoDB:" prefix and
- "is_in" tags.

I hereby propose a mechanical edit to delete those from all
features in Belgium.
The Overpass query to fetch the data is
https://overpass-turbo.eu/s/Qqa

- The openGeoDB tags date to 2008, when the plan was to keep
populations updated from the openGeoDB
  database. This never happened and probably never will.
  Information about OpenGeoDB on the wiki:
https://wiki.openstreetmap.org/wiki/OpenGeoDB
  For an example, see
https://www.openstreetmap.org/node/79382706/history

- The is_in tags are largely obsolete. The administrative
boundaries replace them.
  They're also not uniform in OSM to begin with. Some examples:
  - Beernem:         is_in=Belgie, Vlaanderen, West-Vlaanderen
  - Sint-Andries: is_in=Brugge,West-Vlaanderen,Belgium,Europe
  - Hoekskensstraat: is_in=Lebbeke, Oost-Vlaanderen
  - Meise: is_in=Vlaams-Brabant,Belgium,Europe
           is_in:continent=Europe
           is_in:country=Belgium
           is_in:province=Flemish Brabant

Why remove them? For data users they create the impression that
this is data they can use.
Mappers may be confused about them and waste time maintaining
them. They are not useful to anyone.

I'd like to collectively make a decision ("go" or "no go") by the
end of the month, 29 February.
Please send in your comments, even if it's just "not sure, maybe
we shouldn't do this"!

Kind regards,
Midgard

___
Talk-be mailing list
Talk-be@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-be


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] RFC: removing OpenGeoDB and is_in tags (RFC by 29 Feb 2020)

[joost schouppe]

I say "go"

Op wo 5 feb. 2020 16:37 schreef Midgard :

> Dear mappers
>
> If you ever touched a place node, chances are you saw it was cluttered
> with:
> - tags with a "openGeoDB:" prefix and
> - "is_in" tags.
>
> I hereby propose a mechanical edit to delete those from all features in
> Belgium.
> The Overpass query to fetch the data is https://overpass-turbo.eu/s/Qqa
>
> - The openGeoDB tags date to 2008, when the plan was to keep populations
> updated from the openGeoDB
>   database. This never happened and probably never will.
>   Information about OpenGeoDB on the wiki:
> https://wiki.openstreetmap.org/wiki/OpenGeoDB
>   For an example, see https://www.openstreetmap.org/node/79382706/history
>
> - The is_in tags are largely obsolete. The administrative boundaries
> replace them.
>   They're also not uniform in OSM to begin with. Some examples:
>   - Beernem: is_in=Belgie, Vlaanderen, West-Vlaanderen
>   - Sint-Andries:is_in=Brugge,West-Vlaanderen,Belgium,Europe
>   - Hoekskensstraat: is_in=Lebbeke, Oost-Vlaanderen
>   - Meise: is_in=Vlaams-Brabant,Belgium,Europe
>is_in:continent=Europe
>is_in:country=Belgium
>is_in:province=Flemish Brabant
>
> Why remove them? For data users they create the impression that this is
> data they can use.
> Mappers may be confused about them and waste time maintaining them. They
> are not useful to anyone.
>
> I'd like to collectively make a decision ("go" or "no go") by the end of
> the month, 29 February.
> Please send in your comments, even if it's just "not sure, maybe we
> shouldn't do this"!
>
> Kind regards,
> Midgard
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] RFC: removing OpenGeoDB and is_in tags (RFC by 29 Feb 2020)

[Stijn Rombauts via Talk-be]

 Hi,
I agree with both. I've been removing is_in tags here and there since a few 
months as JOSM encourages to do so.By the way, I also noticed that at some 
places streets (highways) have an is_in tag.
Regards,
StijnRR


Op woensdag 5 februari 2020 16:37:26 CET schreef Midgard 
:  
 
 Dear mappers

If you ever touched a place node, chances are you saw it was cluttered with:
- tags with a "openGeoDB:" prefix and
- "is_in" tags.

I hereby propose a mechanical edit to delete those from all features in Belgium.
The Overpass query to fetch the data is https://overpass-turbo.eu/s/Qqa

- The openGeoDB tags date to 2008, when the plan was to keep populations 
updated from the openGeoDB
  database. This never happened and probably never will.
  Information about OpenGeoDB on the wiki: 
https://wiki.openstreetmap.org/wiki/OpenGeoDB
  For an example, see https://www.openstreetmap.org/node/79382706/history

- The is_in tags are largely obsolete. The administrative boundaries replace 
them.
  They're also not uniform in OSM to begin with. Some examples:
  - Beernem:        is_in=Belgie, Vlaanderen, West-Vlaanderen
  - Sint-Andries:    is_in=Brugge,West-Vlaanderen,Belgium,Europe
  - Hoekskensstraat: is_in=Lebbeke, Oost-Vlaanderen
  - Meise: is_in=Vlaams-Brabant,Belgium,Europe
          is_in:continent=Europe
          is_in:country=Belgium
          is_in:province=Flemish Brabant

Why remove them? For data users they create the impression that this is data 
they can use.
Mappers may be confused about them and waste time maintaining them. They are 
not useful to anyone.

I'd like to collectively make a decision ("go" or "no go") by the end of the 
month, 29 February.
Please send in your comments, even if it's just "not sure, maybe we shouldn't 
do this"!

Kind regards,
Midgard

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
  ___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] RFC: removing OpenGeoDB and is_in tags (RFC by 29 Feb 2020)

[Midgard]

Dear mappers

If you ever touched a place node, chances are you saw it was cluttered with:
- tags with a "openGeoDB:" prefix and
- "is_in" tags.

I hereby propose a mechanical edit to delete those from all features in Belgium.
The Overpass query to fetch the data is https://overpass-turbo.eu/s/Qqa

- The openGeoDB tags date to 2008, when the plan was to keep populations 
updated from the openGeoDB
  database. This never happened and probably never will.
  Information about OpenGeoDB on the wiki: 
https://wiki.openstreetmap.org/wiki/OpenGeoDB
  For an example, see https://www.openstreetmap.org/node/79382706/history

- The is_in tags are largely obsolete. The administrative boundaries replace 
them.
  They're also not uniform in OSM to begin with. Some examples:
  - Beernem: is_in=Belgie, Vlaanderen, West-Vlaanderen
  - Sint-Andries:is_in=Brugge,West-Vlaanderen,Belgium,Europe
  - Hoekskensstraat: is_in=Lebbeke, Oost-Vlaanderen
  - Meise: is_in=Vlaams-Brabant,Belgium,Europe
   is_in:continent=Europe
   is_in:country=Belgium
   is_in:province=Flemish Brabant

Why remove them? For data users they create the impression that this is data 
they can use.
Mappers may be confused about them and waste time maintaining them. They are 
not useful to anyone.

I'd like to collectively make a decision ("go" or "no go") by the end of the 
month, 29 February.
Please send in your comments, even if it's just "not sure, maybe we shouldn't 
do this"!

Kind regards,
Midgard

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be