[Tagging] Is there a way to make tags better?

TLDR: Proposing several technologies to organize tags and help new users. With the rapid community growth, the same concepts tend to be described in more and more ways (tags/values), making the data maintenance and consumption increasingly difficult. taginfo site is an amazing effort to bring

[Tagging] proposal: wikipedia_list and wikipedia_section tags

https://wiki.openstreetmap.org/wiki/Proposed_features/Wikipedia_tag_types I would like to propose two new tags to distinguish between "There is a Wikipedia page about this object" vs "This object is mentioned in a Wikipedia page". Thanks! ___

Re: [Tagging] OSM+Wikidata intro video

; > > > On Wed, Jun 7, 2017 at 12:07 PM, Yuri Astrakhan <yuriastrak...@gmail.com> > wrote: > >> The RDF/SPARQL database that has both OpenStreetMap and Wikidata data in >> the same table is alive and well, and getting considerable usage. To make >> it better unde

[Tagging] OSM+Wikidata intro video

The RDF/SPARQL database that has both OpenStreetMap and Wikidata data in the same table is alive and well, and getting considerable usage. To make it better understood by even wider community, I made an intro video with some examples. This database mostly benefits the object tag validation and

Re: [Tagging] OSM+Wikidata intro video

ely be listed >> under the following page: >> https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution >> >> >> >> On Wed, Jun 7, 2017 at 12:07 PM, Yuri Astrakhan <yuriastrak...@gmail.com> >> wrote: >> >>> The RDF/SPARQL database that ha

Re: [Tagging] New OSM Quick-Fix service

capabilities, and how it can be made more useful. Thanks. On Fri, Oct 13, 2017 at 7:14 PM Warin <61sundow...@gmail.com> wrote: > On 14-Oct-17 08:25 AM, Yuri Astrakhan wrote: > > I would like to introduce a new quick-fix editing service. It allows > users to generate a list of e

[Tagging] New OSM Quick-Fix service

I would like to introduce a new quick-fix editing service. It allows users to generate a list of editing suggestions using a query, review each suggestion one by one, and click "Save" on each change if they think it's a good edit. For example, RU community wants to convert amenity=sanatorium

Re: [Tagging] name with name:en

I agree, identical name & name:xx is very useful when determining the language fallback chain. If asked to show a map in language aa, check if "name:aa" exists, and if not, fallback to "name". In some cases, it might be ok to first try some "name:bb" that most users of "aa" also speak, before

[Tagging] Permanent IDs RFC (was part_of:wikidata)

Permanent IDs has been brought up several times, especially as part of the Wikidata ID discussion. I started a wiki page to outline the requirements and goals, but it might be incomplete, feel free to add / correct / comment. https://wiki.openstreetmap.org/wiki/Permanent_ID Once we reach the

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> > Immutable objects with a previous ID field would solve that. Every edit > will create or delete, no modify. First version's ID will be your > persistent ID. > Erkin, the whole idea of the permanent ID is for it to always point to the same "conceptual" object. If I create a road, and use an ID

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> If you edit a road, a new one would be created and would point to its > invalidated ancestor. Recursively chasing previous ID pointers, you > would eventually have an object without an ancestor. ID of that object > would also be permanent ID of the successor objects. This will also > solve road

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

> > I think permanent IDs should be done with our own Wikidata. Wikibase is a > Wikimedia extension, that means our own Wiki can install OSMData right now. > Then if you want to open a permanent ID for a shop, create a new OSMData > item, and tag the shop with OSMData=M38267 (M instead of Q, for

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

Marc, good points, thanks. Naturally it will never be decided by software. The tools should aid in continuity preservation, not dictate it. We as a community should definitely how each one of these and other cases should be handled -- to define what "permanence" means. > > * What if the shop

Re: [Tagging] part_of:wikidata key

Jo, take a look at * Links to Wikipedia pages about multiple objects There are several cases when an OSM feature matches a part of Wiki(pedia|data) article, and I don't think

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

t; > Regards. > > Le 12 nov. 2017 à 21:17, Yuri Astrakhan <yuriastrak...@gmail.com> a écrit > : > > David, hi, just an thought - could you combine the rationale and examples > sections? The way you have it now is first you describe each concept, and > afterwards

Re: [Tagging] Feature Proposal - Voting - Sinkholes refinement

David, hi, just an thought - could you combine the rationale and examples sections? The way you have it now is first you describe each concept, and afterwards you have the same concept but with a picture. I think it would be better to list each variant with the picture right away. Thanks! On

Re: [Tagging] "building=college" tag missing from building key page

I think this is exactly the issue we had discussed previously: "the concept" vs "the ID" for that concept. When words are used as IDs, they always come with semantic meaning based on your cultural background. The words "college" and "sanatorium" mean different things. With an opaque ID (e.g.

Re: [Tagging] New OSM Quick-Fix service

de (either yes/no, or pick from multiple choices) On Fri, Oct 27, 2017 at 7:08 AM, marc marc <marc_marc_...@hotmail.com> wrote: > Le 14. 10. 17 à 11:56, Andy Townsend a écrit : > > On 13/10/2017 22:25, Yuri Astrakhan wrote: > >> I would like to introduce a new quick-fix edi

Re: [Tagging] Nonbreakable spaces in name tags

Marc, I think that spelling rules is part of the specific language's rules/naming, and should be allowed in tags. If some tool does not normalize unicode for searching, the tool should be fixed (shouldn't be too hard in most cases). Most search engines do these kinds of normalizations before

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

Martin, the goal is not to make OSM fit to Wikidata needs (I'm not even sure what those needs are). The goal is to make it easier to consume OSM data. Pretty much every single OSM data consumer I spoke with complained of how difficult it is to use OSM data - let's try to help them. For this

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

On Wed, Aug 8, 2018 at 1:53 AM Nelson A. de Oliveira wrote: > On Tue, Aug 7, 2018 at 7:35 PM, Yuri Astrakhan > wrote: > > Why would you want railroad stations tagged differently > > and duplicate the same wikidata tag on every part of it? > > Having the same

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

Christoph, you are right that some loosely defined areas like rainforests may not have exact boundaries. We can find limitations and issues in defining/naming/linking pretty much anything, e.g. see discussion for "[Tagging] place nodes for continents". That said, in a large number of cases, it is

Re: [Tagging] Tagging request: missing admin_level tags

Paul Norman wrote OSMBorder about a year ago to help with the border drawing. It generates a pgsql table with line strings (not polygons), each way having the lowest value for the "admin level". So if a way belongs to both a country and a city border, the

Re: [Tagging] Identifying language regions

> and often do not follow any other features. A year ago I was living in a > place where people living there spoke 3 different languages in addition to > the "official" language. > > On Wed, Apr 18, 2018 at 12:41 PM, Yuri Astrakhan <yuriastrak...@gmail.com> &g

[Tagging] Identifying language regions

What would be the best tags to use for mapping language regions? I would like to create a map of primary languages spoken in an area. This will greatly help with multilingual maps, allowing data consumers to calculate which language name tags to use for which locale. This will also give OSM

Re: [Tagging] Identifying language regions

The main problem multilingual map effort is trying to solve is how to calculate the language of the "name" tag. Without it, name tag becomes nearly useless. For example: * An Italian user viewing a feature in China with two tags: "name" and "name:fr". In this case, "name:fr" tag is preferred

Re: [Tagging] Identifying language regions

<a.pirard.pa...@gmail.com> wrote: > On 2018-04-18 21:41, Yuri Astrakhan wrote: > > What would be the best tags to use for mapping language regions? I would > like to create a map of primary languages spoken in an area. This will > greatly help with multilingual maps, allowing data c

Re: [Tagging] Identifying language regions

es that have many or even hundreds of > >> languages. The lines between the places where languages are commonly > >> spoken can be quite fuzzy and often do not follow any other features. > >> A year ago I was living in a place where people living there spoke 3 > >&

Re: [Tagging] Add some tag to identify disputed borders ?

Another related issue -- maritime disputed borders. In the case of Crimea, the disputed border with Russia is over water, thus not showing clearly in many renderings, and over land with Ukraine, showing as a solid line - thus appearing to side with the Russian interpretation. A while ago Paul

Re: [Tagging] Default Language Format; language:default or default:language?

I still think that if this feature is there to document the language of the name tag, we should reuse the default_language [1] -- it is already set on more than 200 large regions, covering most of the world. What's the point of duplicating it? If there is a region where name could be in 2 or more

Re: [Tagging] My proposal for disputed country borders

Rory, thanks for tackling this. You might want to re-upload your proposal to the wiki, as it does appear to be borked at the moment. I think we should not store undisputed territories in the same relation as the disputed ones. Lets just store the disputed regions as individual relations, e.g.

Re: [Tagging] Facts and opinions

Technically it is both -- taginfo gets statistics from the OSM database, but the descriptions, images, and "recommendations" all come from wiki - e.g. https://taginfo.openstreetmap.org/keys/building#wiki comes from wiki. On Mon, Jan 7, 2019 at 9:26 PM Bryan Housel wrote: > > On Jan 7, 2019, at

Re: [Tagging] Draft Proposal: Default Langauge Format

WRT dauflt_language key -- the problem it tries to solve is that rendering software needs to know the language of the "name" tag. OSM editor shouldn't tell the renderer what to use, they should give all the data available, and let renderer developers choose what they need for the specific usecase,

[Tagging] Fwd: OSM Wikibase is now live

Cross-posting to tagging as this new effort should help tagging and metadata management the most. Osmaritans, as of today, OSM Wiki can store structured tag metadata similar to Wikidata. In every possible language, cross-linked, with images, validation rules, or anything else the community

Re: [Tagging] Fwd: OSM Wikibase is now live

Janko, this is an awesome idea! We could use it for templates - e.g. iD editor could show a list of these, and selecting one would pre-populate it. The combination would contain both keys (e.g. something that user would need to type in), and tags (key=specific value). It would be a bit more

Re: [Tagging] Fwd: OSM Wikibase is now live

Hi, > > On 18.09.2018 11:43, Yuri Astrakhan wrote: > > Key:bridge:movable:https://wiki.openstreetmap.org/wiki/Item:Q104 > > Could you make a banner across the top of that page that clarifies that > this is just a copy of information found elsewhere, and that changing > the cont

Re: [Tagging] Fwd: OSM Wikibase is now live

using Wikidata with government applications because is CC0: we > can copy/paste wikidata information to a table and publish the table > with the text of an official act (law).. The text of the official act > MUST be CC0. > > Em 2018-09-18 06:43, Yuri Astrakhan escreveu: > > Cross-p

Re: [Tagging] Fwd: OSM Wikibase is now live

t? > > PS: will be the biggest improvement of 2018, waving with structured data > and CC0 > for government adoption of the OSM! > > > Em 2018-09-18 13:43, Yuri Astrakhan escreveu: > > Peter, I agree it would be much easier to use OSM metadata under CC0, > > and I

Re: [Tagging] Fwd: OSM Wikibase is now live

Sure, we could experiment with storing "preset id" in the OSM features, e.g. preset_id=Q12345 would imply that this feature should have `leisure=pitch+sport=soccer+surface=grass`. Also, in some cases it might even be possible to have multiple presets for the same feature. I don't think we should

Re: [Tagging] Fwd: OSM Wikibase is now live

> table with the text of an official act (law).. The text of the > > official act MUST be CC0. > > > > Em 2018-09-18 06:43, Yuri Astrakhan escreveu: > >> Cross-posting to tagging as this new effort should help tagging and > >> metadata management the most. &g

Re: [Tagging] start_date variants

On Thu, Feb 21, 2019 at 6:51 AM Martin Koppenhoefer wrote: > I am not opposing referencing wikidata in general of course, rather I am > doing it a lot myself, even creating wikidata items from time to time, but > this does not mean we should _move_ information from OSM to wikidata. E.g. > not

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

John, thanks for all the work on this. What surprises me is that some people are so oppose to the principal value of OSM itself -- to allow mappers to map. Disputed territories still need to be mapped - because they reflect reality of the dispute, and because many data consumers need it.

Re: [Tagging] Tagging disputed boundaries

On Thu, Mar 14, 2019 at 7:24 PM Phake Nick wrote: > Come to think of it, if the goal is to represent different perspective of > disputed territory, then mapping disputed territories as disputed territory > using claimed_by=* controlled_by=* does not seems like a good idea, as such > an area in

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

I second Joseph's comment -- the proposal has to be very short for people to review it - e.g. less than a page, with a clear usage examples -- take a few well known ones like Crimea and Kashmir, and just list all features (ways/relations) and their tags. (actually most people don't read beyond

[Tagging] Mismatched tag status

There is currently 267 key & tags on OSM wiki with mismatching STATUS field, as seen in http://tinyurl.com/y62j5m5e - e.g. amenity=fast_food has status=defacto in 10 languages, except German where it is marked as status=in use. Clearly this is not intentional, and should be the same in all

Re: [Tagging] Mismatched tag status

P.S. I'm all for merging the inuse and defacto statuses, but that's a separate discussion. On Tue, Jun 11, 2019, 03:34 Yuri Astrakhan wrote: > Paul, as a programmer, I'm sure you know the difference between a keyword > and the text shown to the user. The issue is not in translation, the

Re: [Tagging] Mismatched tag status

in widespread use, but no formal proposal process has taken place See https://wiki.openstreetmap.org/wiki/Template:Description On Tue, Jun 11, 2019 at 2:43 AM Paul Allen wrote: > On Tue, 11 Jun 2019 at 00:21, Yuri Astrakhan > wrote: > >> There is currently 267 key & tags o

Re: [Tagging] Whispering asphalt

Well, one use case would be for property shoppers to find an area with the quieter asphalt. But yes, all this is a bit far fetched. On the other hand, I do not want to restrict people from mapping whatever interesting information they know, as long as that information is in standardized-ish

Re: [Tagging] Whispering asphalt

I don't think we should do asphalt classification -- too difficult for many cases, and very little value, especially in this case because it is not the "type" of asphalt, it is rather a "feature" of asphalt. Multiple features could exist in the same asphalt - e.g. it could have noise-canceling

Re: [Tagging] Rethinking Map Features

The biggest issue with using Lua/Server side scripting with large lists is that every single data item used on a wiki page requires a separate SQL query (or even multiple ones), due to how mediawiki + wikibase is implemented. On the other hand, relying on TagInfo has some shortcomings - TagInfo

Re: [Tagging] Rethinking Map Features

reate wikibase entries instead, there needs > to be a much easier, friendlier interface, available in all languages, > and I think such a major change should be discussed and be implemented > only if there is consensus that this would be a clear improvement for > most language communities. >

Re: [Tagging] Rethinking Map Features

box content > 5) Edit the description to Indonesian > > It looks like that will still be fewer clicks and fewer mouse strokes > than editing the OSM wikibase data items, and has the benefit of > creating a visible wiki page rather than just editing an obscure data > item. > > Jo

Re: [Tagging] Rethinking Map Features

P.S. I made a short video on how to add descriptions and translations https://www.youtube.com/watch?v=rI1NDD4MtC4 On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan wrote: > Joseph, before you click "edit description", change your language at the > top of the wiki page (make sur

Re: [Tagging] Rethinking Map Features

> Joseph > > On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan > wrote: > >> P.S. I made a short video on how to add descriptions and translations >> >> https://www.youtube.com/watch?v=rI1NDD4MtC4 >> >> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan >>

Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

I agree with Christoph -- every tag used in OSM data must be documented -- otherwise it has near-zero value.. Actually negative value because it confuses people -- some might want to delete it, but they don't know if it is useful, so they just leave it there almost indefinitely. In an ideal world

Re: [Tagging] Keys to which new values can be added without a proposal

Agree, but adding a new tag must happen at the same time as adding a description of what it is (and how it differs from the existing one). The current proposal process is too complicated and lengthy, thus often people just forgo it and add tags without documentation. In my opinion, this is worse

Re: [Tagging] tag templates in the wiki

"OSM meta item" or a "OSM meta dataitem"... naming is hard :) Wikibase is too close to Wikidata, thus has caused some confusion -- that's why I avoid calling it that. I agree that we can (and should!) customize data items editing experience, make it simpler for OSM community. This is

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

One of the issues I frequently observed is that mappers keep trying to add a wikidata=... tag even when there is no perfect match. Having a part:wikidata or a similar tag would help those mappers - indicating that there is no perfect 1:1 match, but someone already looked at this specific object

Re: [Tagging] wikimedia_commons= and image= cleanup

I second - those keys should be cleaned up to be more consistent. My only concern is that we overload the meaning of wikimedia_commons to mean both a single image and a category, using namespace prefix as part of the value. IMO it should be just the name of the file, without the namespace prefix.

Re: [Tagging] charging stations

I agree that we should use the KISS principle, and keep it as simple as possible -- just specify the connector specification type (i.e. a drop-down choice) -- CCS 1.0, CCS 2.0, CHAdeMO, GB/T, Tesla v1, Tesla v2, etc. I think the tag value should include the version number. In theory if a