<div dir="ltr">Let me give you some more examples.<div><br><div>1. place=locality is defiend as "<span style="background-color:rgb(249,249,249);font-family:sans-serif;font-size:13.3px">A named place that has no population". </span></div>In Belarus/Russia there are three categories of objectes which match this definition:<br>- an abandoned settlement<br>- a named natural place<br>- a named spot within a settlement<div>The common name of the first two cases is "урочище" and we usually add this common name to the place proper name when displaying it on a map.<br>As mentioned mentioned in my previous posts, in Russian language we have clear distinction between common and proper names, e.g. "hotel" in "Hotel Maria" is a common name and depending on the context we can skip it and say just "Maria". The same thing applies to the localities. We put just the proper name into the "name" filed and need to put the common name "урочище" into some other field if it is applicable to that kind of locality. Currently we are putting that common name into "name:prefix" field.</div><div><br></div><div>2. In Russian we usually do not display "river" next to the river proper name, e.g. compare name:en="river Dniper" to name:ru="Dniper" but we do display "stream" next to stream proper names in order to distinguish them from rivers.</div><div>waterway=stream is defind as "<span style="background-color:rgb(249,249,249);font-family:sans-serif;font-size:13.3px">A naturally-formed waterway that is too narrow to be classed as a river. An active, able-bodied person should be able to jump over it if trees along it aren't too thick." </span>In other worlds any natural narrow waterway should be tagged as "steam". But in Belarus/Russial we have some very small waterways which are called rivers.</div><div>So we tag them as "waterway=stream" but need to put the common name "река" (en: "river") into some other tag in order to be able to understand that that is actually a river and not a steam.</div><div><br></div><div>3. I've also mentioned in my previous posts the case with settlements.</div><div>In OSM there are 5 categories of a settlement places (city/town/village/hamlet/isolated_dwelling) but in Belarus we have 7 ones. Our real settlement categoreis are widely used e.g. in addresses and differ from the official classification which is put into the "official_status" tag. So currently we tag our settlements as place=* according to OSM's definition and again use the "name:prefix" tag for the local common names.</div></div><div><br></div><div>Do you think that "name:prefix" tag is a good place for a common name which is unwated in the "name" tag but is required to distinguish local categories which cannot be precisely matched to the available OSM tags?</div><div><br></div><div>Best regards,</div><div>Eugene</div></div><br><div class="gmail_quote"><div dir="ltr">пн, 10 дек. 2018 г. в 05:03, Michael Patrick <<a href="mailto:geodesy99@gmail.com">geodesy99@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>Can OSM become a geospatial database?</pre></blockquote><div> It currently fits almost any definition of 'GeoSpatial' database. Even if you ignore any intrinsic properties you might select to define
'GeoSpatial' database, extrinsic properties would define it as such, for example the UN-HCR, the U.S. National Geospatial Agency, The U.S. National Park Service, and probably thousands of others use it to perform <a href="https://en.wikipedia.org/wiki/Create,_read,_update_and_delete#Database_applications" target="_blank">C.R.U.D.</a> operations on a continuous basis. <br></div><div><br></div><div>That being said, from a software development perspective, it perhaps more resembles a set of <a href="https://en.wikipedia.org/wiki/Federated_database_system#Heterogeneity" target="_blank">loosely federated database system</a>. So the technical approaches are not as straightforward as an ordinary database, one probably should treat it as a <a href="https://en.wikipedia.org/wiki/Data_lake" target="_blank">data lake</a> or a nascent <a href="https://en.wikipedia.org/wiki/Data_warehouse#History" target="_blank">data warehouse</a> - if one were unkind, sometimes it can seem like a <a href="https://dl.acm.org/citation.cfm?id=3209911" target="_blank">data swamp</a>. In practice, this means a chain of <a href="https://en.wikipedia.org/wiki/Extract,_transform,_load" target="_blank">ETL</a> operations, rather than a single straight forward database query. And what makes this even weirder is that, in some ways, OSM is a hybrid of a <a href="https://en.wikipedia.org/wiki/Relational_database" target="_blank">relational</a> and a <a href="https://en.wikipedia.org/wiki/Graph_database#Labeled-Property_Graph" target="_blank">graph</a> database. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>Right now OSM is a collection of dots and lines with some generic tags for
rendering them on a map. They do compile into nice maps but does it really
work when it comes to searching for objects of real life categories? ...</pre></blockquote><div>Superficially, that seems the case, but only because of expectations. expanding the perspective, IMHO, it is actually fairly robust and sophisticated considering what it is required to do. It actually permits use cases which would be intolerable for mundane systems. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>To wrap it up it is hard to impossible to get objects of some real live
category from OSM database in order for example to highlight them on a
map or to list them in search results.
</pre></blockquote><div>I would agree that it is hard, but not impossible. Certainly in a single step for the entire data space. In the 'stream' example, one has to work across the basic data type <a href="https://wiki.openstreetmap.org/wiki/Elements" target="_blank">elements</a> of nodes, ways, and relations, then across <a href="https://taginfo.openstreetmap.org/keys" target="_blank">keys</a>, <a href="https://taginfo.openstreetmap.org/tags" target="_blank">tags</a>, and <a href="https://taginfo.openstreetmap.org/relations" target="_blank">relation types</a>. And even within those, there are wildly different purposes, like base geometric meanings like <a href="https://taginfo.openstreetmap.org/relations/multipolygon" target="_blank">multipolygon</a> alongside high level abstractions like <a href="https://taginfo.openstreetmap.org/relations/surveillance" target="_blank">surveillance</a>. So, if one were building some sort of generic software utility, one has to inventory the relative prevalence of the structures above, and bound the problem accordingly along with leveraging aspects like the geometric bounding box. Once you get <a href="https://dictionary.cambridge.org/us/dictionary/english/in-the-weeds" target="_blank">down in the weeds</a>, like with 'amenity', you are in the <a href="https://en.wikipedia.org/wiki/Natural_language_processing" target="_blank">NLP</a> realm, and would have to supplement from an external utility like <a href="https://en.wikipedia.org/wiki/WordNet" target="_blank">WordNet</a> - for example using <a href="https://www.geeksforgeeks.org/get-synonymsantonyms-nltk-wordnet-python/" target="_blank">synsets</a> and <a href="https://en.wikipedia.org/wiki/Semantic_similarity" target="_blank">semantic distance</a>. ... see
<a href="https://wiki.openstreetmap.org/wiki/OSM_Semantic_Network" target="_blank">OpenStreetMap Semantic Network</a>
.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>There are two workarounds used right now. The first one is to bind some new
tags to local categories ... The second one is to put category name into "name" tag, e.g. "Liberty
avenue", "Blue lake", "South park". ...
I invision the following solution here.
* First of all, the "name" tag should containt proper name only.</pre></blockquote><div>I agree, but people are people, and for ordinary people, if you ask three people to name something, you'd get three different 'names' at different levels of <a href="https://rationalwiki.org/wiki/Prototype_theory#Basic_level_categories" target="_blank">abstraction</a> (
subordinate, basic, or superordinate). Point and ask three people "What's that" and you'll get "The Columbia River", "North Channel", or "
<span class="gmail-m_-2584207112976570464gmail-oedJWe">Knappa, Knappa Slough", so even the proper names will vary. </span>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>* Secondly, introduce a new tag for the real life language specific
category name. I know that "name:prefix/postfix" key was originally
introduced for another purpose but it can be a candidate here as well. Note
that in some languages the place of category name relative to the proper
name matters.</pre></blockquote><div> Because of the complexities noted previously, the weight of legacy information, and maintenance complexity ( occasional refactoring ), a more or less parallel scheme would be unrealistic inside of OSM. Possibly one of the <a href="https://wiki.openstreetmap.org/wiki/Category:Semantics" target="_blank">OSM semantic projects</a> might provide similar capability. Implementing as you describe would be the Mother of All Automated Edits. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>* Thirdly, in order to make the life of renderers simple, introduce one
more tag for holding the name which can be displayed on maps as is without
any modifications, e.g. "display_name". This tag may contain whatever
content is considered locally appropriate specifically for rendering on
maps. </pre></blockquote><div>I'm not sure I understand this, but superficially it seems to break the convention of separation of data and symbolization (heavily dependent on the specifics at the endpoint). <br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">There are people in the community that are <i>far</i> more knowledgeable than me on these themes, I suggest you reach out to them. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">For me, a mental model of monolithic OSM isn't useful. It isn't unique to OSM, even what appear to be simple concepts like Employee Name in an enterprise database become very complex when applied to different cultures - I one reconciled a record for a nurse who had 13+ different versions, all perfectly 'legal' in the corporate records.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Michael Patrick<br></div></div></div></div></div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>