Can OSM become a geospacial database?

classic Classic list List threaded Threaded
106 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

Daniel Koć
W dniu 09.12.2018 o 12:34, Eugene Podshivalov pisze:
> How would you map American "streamlet", "brook", "creek" and "river"
> to the two generic "stream" and "river" in OSM?
> Currently they are just putting in the name field, so the only ways to
> fide all "brooks" is by searching the name fields which is not a
> proper database approach.


And what is the definition of them? How are they different?

I think these are really not too meaningful names, so searching in names
seems to be proper if you want to find them. The question is - what for,
what will it mean?


--
"Excuse me, I have some growing up to do" [P. Gabriel]



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

Warin
On 10/12/18 07:12, Daniel Koć wrote:

> W dniu 09.12.2018 o 12:34, Eugene Podshivalov pisze:
>> How would you map American "streamlet", "brook", "creek" and "river"
>> to the two generic "stream" and "river" in OSM?
>> Currently they are just putting in the name field, so the only ways to
>> fide all "brooks" is by searching the name fields which is not a
>> proper database approach.
>
> And what is the definition of them? How are they different?
>
> I think these are really not too meaningful names, so searching in names
> seems to be proper if you want to find them. The question is - what for,
> what will it mean?
>
>
Those are in the name field as those are part of their names.

They are not some technical description of the waterway.


Is there a professional differentiation between these terms?


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

Wolfgang Zenker
In reply to this post by Eugene Podshivalov
* Eugene Podshivalov <[hidden email]> [181209 12:34]:
> вс, 9 дек. 2018 г. в 14:10, Marc Gemis <[hidden email]>:

>> We have tags for that (waterway=stream, ditch, ... / amenity=school,
>> college, university, kindergarten), I don't understand why we should
>> change the usage of name for that.

> How would you map American "streamlet", "brook", "creek" and "river" to the
> two generic "stream" and "river" in OSM?
> Currently they are just putting in the name field, so the only ways to fide
> all "brooks" is by searching the name fields which is not a proper database
> approach.

Most probably you would not want to look for all "brooks", because
"brook" is just one of multiple words that mean the same thing. There is
no semantic difference between a "brook" and a "stream" in general
nowadays. Its just that in different regions of the english speaking
world different words were commonly used, and people in America used
whatever word they were familiar with.

Wolfgang
( lyx @ osm )

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

Michael Patrick
In reply to this post by Eugene Podshivalov
Can OSM become a geospatial database?
 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 C.R.U.D. operations on a continuous basis.

That being said, from a software development perspective, it perhaps more resembles a set of loosely federated database system. So the technical approaches are not as straightforward as an ordinary database, one probably should treat it as a data lake or a nascent data warehouse  - if one were unkind, sometimes it can seem like a data swamp. In practice, this means a chain of ETL 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 relational and a graph database.  
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? ...
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.
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.
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 elements of nodes, ways, and relations, then across keys, tags, and relation types. And even within those, there are wildly different purposes, like base geometric meanings like multipolygon alongside high level abstractions like surveillance. 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 down in the weeds, like with 'amenity', you are in the NLP realm, and would have to supplement from an external utility like WordNet - for example using synsets and semantic distance. ... see  OpenStreetMap Semantic Network .

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.
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 abstraction ( subordinate, basic, or superordinate). Point and ask three people "What's that" and you'll get "The Columbia River", "North Channel", or " Knappa, Knappa Slough", so even the proper names will vary. 
* 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.
 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 OSM semantic projects might provide similar capability. Implementing as you describe would be the Mother of All Automated Edits.
* 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. 
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).

There are people in the community that are far more knowledgeable than me on these themes, I suggest you reach out to them.

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.

Michael Patrick

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

Eugene Podshivalov
Let me give you some more examples.

1. place=locality is defiend as "A named place that has no population". 
In Belarus/Russia there are three categories of objectes which match this definition:
- an abandoned settlement
- a named natural place
- a named spot within a settlement
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.
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.

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.
waterway=stream is defind as "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." 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.
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.

3. I've also mentioned in my previous posts the case with settlements.
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.

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?

Best regards,
Eugene

пн, 10 дек. 2018 г. в 05:03, Michael Patrick <[hidden email]>:
Can OSM become a geospatial database?
 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 C.R.U.D. operations on a continuous basis.

That being said, from a software development perspective, it perhaps more resembles a set of loosely federated database system. So the technical approaches are not as straightforward as an ordinary database, one probably should treat it as a data lake or a nascent data warehouse  - if one were unkind, sometimes it can seem like a data swamp. In practice, this means a chain of ETL 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 relational and a graph database.  
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? ...
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.
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.
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 elements of nodes, ways, and relations, then across keys, tags, and relation types. And even within those, there are wildly different purposes, like base geometric meanings like multipolygon alongside high level abstractions like surveillance. 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 down in the weeds, like with 'amenity', you are in the NLP realm, and would have to supplement from an external utility like WordNet - for example using synsets and semantic distance. ... see  OpenStreetMap Semantic Network .

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.
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 abstraction ( subordinate, basic, or superordinate). Point and ask three people "What's that" and you'll get "The Columbia River", "North Channel", or " Knappa, Knappa Slough", so even the proper names will vary. 
* 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.
 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 OSM semantic projects might provide similar capability. Implementing as you describe would be the Mother of All Automated Edits.
* 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. 
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).

There are people in the community that are far more knowledgeable than me on these themes, I suggest you reach out to them.

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.

Michael Patrick
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Can OSM become a geospacial database?

dieterdreist

Am Fr., 28. Dez. 2018 um 12:26 Uhr schrieb Eugene Podshivalov <[hidden email]>:
Let me give you some more examples.

1. place=locality is defiend as "A named place that has no population". 
In Belarus/Russia there are three categories of objectes which match this definition:
- an abandoned settlement
- a named natural place
- a named spot within a settlement


agreed, place=locality is about a named place, and is so generic, it can mean a whole lot of different things. Sooner or later someone might come up with a proposal to subtag these, or we might have invented in the meantime more specific tags for natural objects and other things, so that people don't tag them as locality any more.


 
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.
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.


just keep doing it ;-)

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1 ... 3456