Can OSM become a geospacial database?

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

Re: Can OSM become a geospacial database?

Kevin Kenny-3
On Thu, Dec 6, 2018 at 10:58 AM Eugene Podshivalov <[hidden email]> wrote:
Let's look into some other examples.
Settlements are supposed to be defined with place=city/town/village/hamlet/isolated_dwelling tags. The value depends on the size of the settlement.
But in Belarus for example we call our settlements "город" (can be city or town), "городской посёлок" (can be town or village), "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
When people use the maps created form OSM database they don't care about the generic OSM categorization of settlements. They need their local category names.
So what tag should be put those local category names in?


Several thoughts.

If it's something that people usually use in referring to the place, put it in the name. So 'Nizhny Novgorod' would be named thus (sorry, I don't have the time to try to enter Cyrillic on a US keyboard). 

If it refers to an administrative entity, put an appropriate level in the boundary=administrative.

Where I live, the formal designation of a place usually fails to match the OSM definition. We have formal 'hamlet's that have 60000 inhabitants, and chartered cities with only a few hundred. We use boundary=administrative with an appropriate admin_level (and I've been lobbying for administrative:entity to give a word for the legal designation: county, borough, city, township, village, hamlet, ward, precinct, community district, ... but that hasn't gotten any significant traction yet). The 'admin_level' is not strictly hierarchical here, because our system for drawing administrative boundaries is, "there's no system: deal with it!" The OSM definition is useful for mapping - deciding at what level to render the name and in how big a font, for instance. Few people around here actually care when using a map what formal political organization the place has. Whether the community I grew up in was a Hamlet or a Village made very little practical difference. You'd have a different set of local politicians, and the cops might work for the county instead of the town, but the type of place was clearly much less important than the borders of the place.

If it's a question about the common name rather than the formal name, that's usually dealt with by name_1, etc. That way, the city called "New York" can be disambiguated, "New York City" (informal, very commonly used to make it clear that it's New York City and not New York State), "The City of New York" (what appears on most of its legal papers), "The City of Greater New York" (the way it's styled in its charter).

If it's neither a component of the name of the place nor a formal designation of a political boundary, can you explain more why it's important? Is it immediately obvious in the field that one thing is a 'gorod' and another is a 'gorodskoy posyolok,' while a third is a 'perevnya?' If so, what is the difference? What's the problem we're trying to solve?

_______________________________________________
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
In reply to this post by Eugene Podshivalov
Am Do., 6. Dez. 2018 um 16:58 Uhr schrieb Eugene Podshivalov <[hidden email]>:
Let's look into some other examples.
Settlements are supposed to be defined with place=city/town/village/hamlet/isolated_dwelling tags. The value depends on the size of the settlement.


this is not a hard requirement, there is a suggestion to do it like this, and there is an explicit note that it can differ by country/context.
For example I would see the distinction between a hamlet and a village in a functional criterion, while in Europe it is often clear what is a town and what is a big village, from looking at the legal situation (history is usually important), it can be in the name / people usually know it.


 
But in Belarus for example we call our settlements "город" (can be city or town), "городской посёлок" (can be town or village), "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
When people use the maps created form OSM database they don't care about the generic OSM categorization of settlements. They need their local category names.
So what tag should be put those local category names in?



You should create a scale of significance which correlates more or less to the situation and adopt the standard place tags, plus add a subtag for the local classes. How do they work, what does characterize them? Is it about the administration hierarchy?

Cheers,
Martin

_______________________________________________
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?

Paul Allen
On Thu, Dec 6, 2018 at 4:38 PM Martin Koppenhoefer <[hidden email]> wrote:
For example I would see the distinction between a hamlet and a village in a functional criterion, while in Europe it is often clear what is a town and what is a big village, from looking at the legal situation (history is usually important), it can be in the name / people usually know it.

In the UK, many many years ago, these distinctions applied:

To be a city the place had to have a cathedral.

To be a town the place had to have a market.

To be a village the place had to have a church.

To be a hamlet it didn't even have a church but did have more than one dwelling.

The distinctions were never that hard and fast, and have only loosened over time.  A city now has a
cathedral or a royal charter or a university or just feels like calling itself a city.  A large village in England
can be larger than a large town in Wales.  Some towns no longer have markets, but once did.
Some villages no longer have churches, but once did.  Etc.

I see that the wiki suggests using those terms as an indicator of population rather than anything else.
Since some renderers assume those values are indicators of population, maybe that's what we
should be using explicitly and drop the city/town/village/hamlet.  Except, of course, population is often
left untagged (and is sometimes that information is simply not available).

The real world is messy.

--
Paul


_______________________________________________
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 Alvin Villar
In reply to this post by Eugene Podshivalov
On Thu, Dec 6, 2018, 11:58 PM Eugene Podshivalov <[hidden email] wrote:
But in Belarus for example we call our settlements "город" (can be city or town), "городской посёлок" (can be town or village), "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
When people use the maps created form OSM database they don't care about the generic OSM categorization of settlements. They need their local category names.
So what tag should be put those local category names in?

If these settlement types are legally-defined types in your country, you could use the designation=* tag with your country-specific values alongside the usual place=* tags.


_______________________________________________
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
In reply to this post by Paul Allen
чт, 6 дек. 2018 г. в 19:30, Kevin Kenny <[hidden email]>:  
If it's neither a component of the name of the place nor a formal designation of a political boundary, can you explain more why it's important? Is it immediately obvious in the field that one thing is a 'gorod' and another is a 'gorodskoy posyolok,' while a third is a 'perevnya?' If so, what is the difference? What's the problem we're trying to solve?  
They cannot be put into name tag because they are not part of the proper name. It would be like renaming "Paris" into "Paris city". 
Neither the admin boundary scheme can help here because one settlements of different local category can belong to one and the same admin level.
Here are a couple of cases when the knowlege of these local categories is needed.
* They are used in address strings
* They are sumtimes displayed in maps to resolve ambiguousness (when two neighbourhood settlement have one and the same name and differ only in category name).
* There is a common practice in Belarus to draw residential area of different settlemnet types in different color.


чт, 6 дек. 2018 г. в 19:48, Paul Allen <[hidden email]>:
On Thu, Dec 6, 2018 at 4:38 PM Martin Koppenhoefer <[hidden email]> wrote:
For example I would see the distinction between a hamlet and a village in a functional criterion, while in Europe it is often clear what is a town and what is a big village, from looking at the legal situation (history is usually important), it can be in the name / people usually know it.

In the UK, many many years ago, these distinctions applied:

To be a city the place had to have a cathedral.

To be a town the place had to have a market.

To be a village the place had to have a church.

To be a hamlet it didn't even have a church but did have more than one dwelling.

The distinctions were never that hard and fast, and have only loosened over time.  A city now has a
cathedral or a royal charter or a university or just feels like calling itself a city.  A large village in England
can be larger than a large town in Wales.  Some towns no longer have markets, but once did.
Some villages no longer have churches, but once did.  Etc.

I see that the wiki suggests using those terms as an indicator of population rather than anything else.
Since some renderers assume those values are indicators of population, maybe that's what we
should be using explicitly and drop the city/town/village/hamlet.  Except, of course, population is often
left untagged (and is sometimes that information is simply not available).

The real world is messy.

--
Paul

_______________________________________________
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?

Michael Patrick
In reply to this post by Eugene Podshivalov

great you name carpenters, because there were actually some problems in the
past classifying people working with wood. ... Can you explain the difference between a framer, a carpenter, a cabinet maker, a joiner, a finish carpenter, a timberman, a ring builder, a jerry man, a binder?

There could only be a problem classifying trades if existing lexicons are ignored. At least in the U.S., currently, there are fairly exact definitions for trade classifications, down to the types of tools, specific materials, certification, and processes where required.

Example: "Grade 9 roofers must be fully skilled in installing new roofs. They must have the ability to apply the starter row of shingles to insure that they overlap properly and that they are securely fastened to the subsurface to eliminate possibility of leaks. On built-up roofs, they must be skilled in applying roofing felt, asphalt and gravel, or other topping material, and in sealing joints of roofing accessories with asphalt. In addition to work at the grade 7 level, the grade 9 roofers must be able to install and repair the metal roofing accessories themselves, such as gravel guards, flashings, gutters, valleys, vents, pipes, and chimneys.They also must have the ability to cut and form metal accessories to meet roofing requirements, to fasten them to roofs with nails or screws, to solder metal joints, and to cut and shape shingles to fit around the accessories. In comparison with the grade 7 level, the grade 9 roofers also must be familiar with a greater variety of roofing materials and their uses and methods of installation. They must know how to apply wood, asbestos, slate tile, and composition shingles; metal roofing panels; roofing felt and asphalt. When required, they must be able to apply asbestos siding materials.In addition to the hand tools used at the grade 7 level, they must be skilled in the use of shingle cutters, metal snips and saws. "

International Open BIM systems standards ( Building Information Management, which covers the entire life cycle from natural site, through construction and operation, to demolition and site restoration ) have even finer grain of detail.

Some of them might be synonyms, some reflect regional differences (e.g. AE
vs. BE)?

Since the labor and materials supply chain is international, there are multi-lingual crosswalk tables between the U.S. and E.U., between the E.U. and the member countries.

A casual observer might observe a job site during a pour, and classify the workers as 'concrete workers', when they are actually Formwork Carpenters.

Folksonomies like OSM have benefits, but as they expand, the downsides begin to matter, and there usually isn't an effective mechanism to refactor them.

Sometimes the apparent complexity of these existing standards appear intimidating, but they all have a root, branches, and leaves, and one can select the level(s) of abstraction which are coincident with common language. i.e. in one place you can see what the differences and similarities "... between a framer, a carpenter, a cabinet maker, a joiner, a finish carpenter, a timberman, a ring builder, a jerry man, a binder" are, and where your term lies in the hierarchy. Sometimes, the 'root' concept and groupings are not obvious.

This also leaves room for reconciling it with other classifications - Japanese style carpentry roles are more or less orthogonal to Western style, more intensely aligned to product, the worker literally might select and fell the tree, mill that wood, and eventually carve it to shape in it's final position.

It's a question, to a degree, of "re-inventing the wheel". There are already existing tagging schemes in the world ( some going back to the 1700's, from guilds and registries ). It might be worth a few minutes to seek those out, and adopt from those.

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?

Mateusz Konieczny-3
In reply to this post by Eugene Podshivalov
6. Dec 2018 16:56 by [hidden email]:

Let's look into some other examples.
Settlements are supposed to be defined with place=city/town/village/hamlet/isolated_dwelling tags. The value depends on the size of the settlement.
But in Belarus for example we call our settlements "город" (can be city or town), "городской посёлок" (can be town or village), "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
When people use the maps created form OSM database they don't care about the generic OSM categorization of settlements. They need their local category names.
So what tag should be put those local category names in?


 You may start using an additional tag to add information about legal designation of a
settlement (I suspect that tag like this already exists).


_______________________________________________
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?

Mateusz Konieczny-3
In reply to this post by Eugene Podshivalov
6 Dec 2018, 12:51 by [hidden email]:
Another solution is to always put category name into "name" field. "Paris" would become "City of Paris" or "Paris city".
name tag is for name, not for category

_______________________________________________
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
In reply to this post by Michael Patrick


sent from a phone

> On 6. Dec 2018, at 23:38, Michael Patrick <[hidden email]> wrote:
>
> This also leaves room for reconciling it with other classifications - Japanese style carpentry roles are more or less orthogonal to Western style,


you are right that there are dictionaries about this stuff, but you will have to have a basic idea in order to make use of them, particularly if English is not your native language, you might look up terms that you are familiar with, and might not be aware that you are missing another relevant term, or that the term is not a translation with more or less the same meaning but only loosely connected.

Language is reflecting reality, and if the way construction work is organized is different in different countries, also the terms describing the workers will not be matchable.

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap. We usually try to create (not too) coarse classes/groups and use subtags to distinguish minor differences.

FWIW, with regard to dictionaries, in the case of the misleading roofer description, it was copied exactly from the English wikipedia article on roofers, which is in itself not consistent there (mixes carpentry and roofing in the article).

Cheers, Martin
_______________________________________________
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?

Mateusz Konieczny-3
In reply to this post by Sergio Manzi



6 Dec 2018, 01:45 by [hidden email]:

I mean, in a more general way and going back to the pond case,

object 1:

natural=water
water=pond
water:RU=пруд

object 2

natural=water
water=pond
water:RU=копанка

would respect both our sensibility to "see" the two objects as ponds and their sensibility to "see" the two as whatever they think they are

It would be preferable to use English words - it is likely that this classification is
not unique to Russia.

_______________________________________________
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?

Joseph Eisenberg
In reply to this post by Eugene Podshivalov
On 12/7/18, Eugene Podshivalov <[hidden email]> wrote:

>> чт, 6 дек. 2018 г. в 19:30, Kevin Kenny <[hidden email]>:
>> ... Is it immediately obvious in the field that one thing is a
>> 'gorod' and another is a 'gorodskoy posyolok,' while a third is a
>> 'perevnya?' If so, what is the difference? ...
>
> They cannot be put into name tag because they are not part of the proper
> name. It would be like renaming "Paris" into "Paris city".
> Neither the admin boundary scheme can help here because one settlements of
> different local category can belong to one and the same admin level.
> Here are a couple of cases when the knowlege of these local categories is
> needed.
> 1) They are used in address strings

In this case they should be included in at least one of the name tags,
perhaps official_name="XXX Gorod"  or alt_name="XXX Gorod" etc.

Her in Indonesia, admin_level 5 can be a "Kabupaten" ("Regency" or
county) or "Kota" ("City"), so we use:
name = "Kabupaten Jayapura" and
name = "Kota Jayapura"
for the two, adjacent administrative entities. Jayapura is also a
place=city which is tagged as a node, without the "Kota", but the
official_name could be "Kota Jayapura" as well.
You could also use official_name or alt_name for these situations, if
it fits better in Belarus

> 2) They are sometimes displayed in maps to resolve ambiguousness (when two
> neighbourhood settlement have one and the same name and differ only in
> category name).

If they should normally be displayed this way on local maps, then the
full name should certainly be included in the "name=" tag eg name="XXX
Gorodskoy Posyolok", if local people expect the full name to be
displayed on maps.

The "name" tag is for the full name as used by local people, and often
includes a word that describes the type of features. Eg "Rio Grande"
is the correct name for the "Big River" on the USA-Mexico border, even
though it just means "big river".

"The Central Valley" is the correct name of the very large valley or
plain in the center of California.

> * There is a common practice in Belarus to draw residential area of
> different settlement types in different color.

This would require a different solution. If it is only the residential
area that is shown in a different color, then you can tag the area as
usual, with landuse=residential.

Then add an additional subtag, such as residential=village,
residential=town and residential=city. This will then make it quite
easy to render each type of residential area differently.

If the current settlement names are not precise enough, you could use
residential=small_town, residential=large_town, etc, to fit the
meaning of  "gorod", "perevnya" and such.

But I agree that the current 5-level system of settlements, from
isolated_dwelling to city, can probably be adapted to fit the common
usage of the words in Belarus.

_______________________________________________
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
you are right that there are dictionaries about this stuff, but you will have to have a basic idea in order to make use of them, particularly if English is not your native language, you might look up terms that you are familiar with, and might not be aware that you are missing another relevant term, or that the term is not a translation with more or less the same meaning but only loosely connected.

Trade in goods and services is international - most countries publish their classifications in their official language(s) and script. I looked looked at Mozambique at random, it's 520 pages of similar tables as the ISCO. The one that don't publish their own probably default to the ISOC standard, or like North Korea, don't play well with others.

(Sample extract ... some of the fonts for the Asian languages didn't copy properly)
Ireland - CSO Standard Employment Status Classification
Israel - (SCO) די יחלשמ לש דיחאה גוויסה
Italy -  Classificazione delle professioni (CP 2011)
Jamaica - Jamaica Standard Occupational Classification (JSOC 1991)
Japan - (JSOC)
Korea, Republic of -
Latvia - Profesiju klasifikators (PK)
Lithuania -  Lietuvos profesijų klasifikatorius (LPK)
Malaysia -  Malaysia Standard Classification of Occupations (MASCO 2008)
Maldives - International Standard Classification of Occupations (ISCO)
Mauritius - National Standard Classification of Occupations (NASCO-08)
Micronesia, Federated States of - International Standard Classification of Occupations (ISCO)
Mozambique - Classificação das Profissões de Moçambique revisão 2 (CPM Rev2)
Nauru - International Standard Classification of Occupations (ISCO)
Netherlands - Standaard Beroepenclassificatie 1992 (SBC 1992)
New Zealand - Australian and New Zealand Standard Classification of Occupations (ANZSCO)
Norway - Standard for yrkesklassifisering (STYRK-08)
Palestine -  (PSCO) ل د ط ا ير ا ا ف
Panama - Clasificación Nacional de Ocupaciones (CNO 2010)
Paraguay - Clasificación Paraguaya de Ocupaciones (CPO)
Philippines - 2011 Philippine Standard Occupational Classification (PSOC)
Poland - Klasyfikacja zawodów i specjalności na potrzeby rynku pracy (KZiS)
Portugal - Classificação Portuguesa das Profissões (CPP/2010)
Qatar - Occupations
Romania - Clasificarea Ocupatiilor din Romania (COR)
Russian Federation - Общероссийский классификатор занятий (ОКЗ), Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР)
Sao Tome and Principe - Classicação das Profissões (CNP)
Serbia - Jedinstvena nomenklatura zanimanj / Klasifikacija zanimanja (JNZ / KZ)
Singapore - Singapore Standard Occupational Classification (SSOC 2010)
Slovakia -  Štatistická klasifikácia zamestnaní (ISCO-08)
Spain - Clasificación Nacional de Ocupaciones (CNO-11)
Suriname - International Standard Classification of Occupations (ISCO-08)
Sweden - Standard för svensk yrkesklassificering (SSYK)

Language is reflecting reality, and if the way construction work is organized is different in different countries, also the terms describing the workers will not be matchable.

Yes, there are similarities and differences. The Japanese top-level categories make a clear distinction between the wooden structure and other structures that I guessed at in my previous post. But it is visible there. The sub-items are what provide the ability to match. That is why there are 'crosswalks', a means like a document or table describing a mechanism or approach to translating, comparing or moving between standards, converting skills or content from one discipline to another. If you don't want to use the local one, there is an international one, and eventually someone can reconcile the local one.

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap. We usually try to create (not too) coarse classes/groups and use subtags to distinguish minor differences.

Classification schemes are always a Goldilocks Problem -  if it is too simple, it will grow awkwardly as it encounters edge cases and exceptions, it it is too complex, it will be ignored or even worse applied incorrectly. Usually you will see only three levels, and maybe a sparse fourth. The 'not too' qualifier mentioned is the issue. The trick is to define the hierarchy, and then assign the term to the proper level in the hierarchy. I would submit that domain experts coming to agreement worldwide over decades have had a better opportunity to refine these aspects than any small set of individuals in separate language communities ( for all I know, the Germans may have already solved this ).

FWIW, with regard to dictionaries, in the case of the misleading roofer description, it was copied exactly from the English wikipedia article on roofers, which is in itself not consistent there (mixes carpentry and roofing in the article).

My text was not copied from Wikipedia -  I only work from original authoritative source documents, in this case the U.S. Department of Labor, and the example I gave was an extract of an intermediate level, at the 'leaf' level ( click on the Details tab ) it goes down to the specific tools used: ... i.e. Hoists — Hydraulic swing beam hoists; Power hoists; Shingle ladder hoists; Trolley track hoist". Of course Wikipedia might be inconsistent, I occasionally use a Wikipedia reference if accurately gives a more general description than a more precise technical document.

That is a fairly extreme hierarchy, but needed for it's intended use - supporting crosswalks.
Employment-->Industry (Construction)-->Occupation ( Roofers)-->Details (Tools)-->Hoists ( Power, Swing, Trolley, etc.) ... most of the utility for ordinary people is in the top three levels.If I was asked to send a wood building 'roofer' to Japan, I will send a Log Peeler / Tile Setter instead, based on the tools and materials.  

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap.

There is no need for that. In my work with cross-national data, I reference the source hierarchy (and crosswalk if needed if I am integrating to someone else's work), fill in the two top levels, then add mine at the appropriate level. On the rare occasion, if there is a significant difference, I will invoke the fourth level - the next person using my classification then is automatically alerted why I used the wildly unexpected 'bark peeler' instead of 'roofer', I don't list all the tools and materials, just the two categories that made the distinction. If it is critical I might put the specific tool name.( 5th level ).

It is actually beneficial not to add everything. Over time, the entries actually in the data can be scanned and dichotomous keys created, where by asking a set of yes/no questions, one can get to an already used entry. I've seen school children get to exact species identification doing this, with no knowledge of the classification system itself. So things actually become easier for new users in the beginning.

There seems to be some sort of perception that standard classifications discourage diversity, but the opposite is true. As new concepts appear, they can be preserved and not force fit to the existing biases of previous categories - because there is a way to do that without disturbing the bulk of the existing base.

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
I assume that the aforementioned issue with the official classification of settlement being deferent from the place tags values is faced in many countries.
So some common approach is needed here. There were many solutioned listed above, but it seems that only the following two are suitable for defining the local classification:
1.  in the respective category tag appended with language code, e..g. "place:RU="
2.  in the "designation" tag

пт, 7 дек. 2018 г. в 07:32, Michael Patrick <[hidden email]>:
you are right that there are dictionaries about this stuff, but you will have to have a basic idea in order to make use of them, particularly if English is not your native language, you might look up terms that you are familiar with, and might not be aware that you are missing another relevant term, or that the term is not a translation with more or less the same meaning but only loosely connected.

Trade in goods and services is international - most countries publish their classifications in their official language(s) and script. I looked looked at Mozambique at random, it's 520 pages of similar tables as the ISCO. The one that don't publish their own probably default to the ISOC standard, or like North Korea, don't play well with others.

(Sample extract ... some of the fonts for the Asian languages didn't copy properly)
Ireland - CSO Standard Employment Status Classification
Israel - (SCO) די יחלשמ לש דיחאה גוויסה
Italy -  Classificazione delle professioni (CP 2011)
Jamaica - Jamaica Standard Occupational Classification (JSOC 1991)
Japan - (JSOC)
Korea, Republic of -
Latvia - Profesiju klasifikators (PK)
Lithuania -  Lietuvos profesijų klasifikatorius (LPK)
Malaysia -  Malaysia Standard Classification of Occupations (MASCO 2008)
Maldives - International Standard Classification of Occupations (ISCO)
Mauritius - National Standard Classification of Occupations (NASCO-08)
Micronesia, Federated States of - International Standard Classification of Occupations (ISCO)
Mozambique - Classificação das Profissões de Moçambique revisão 2 (CPM Rev2)
Nauru - International Standard Classification of Occupations (ISCO)
Netherlands - Standaard Beroepenclassificatie 1992 (SBC 1992)
New Zealand - Australian and New Zealand Standard Classification of Occupations (ANZSCO)
Norway - Standard for yrkesklassifisering (STYRK-08)
Palestine -  (PSCO) ل د ط ا ير ا ا ف
Panama - Clasificación Nacional de Ocupaciones (CNO 2010)
Paraguay - Clasificación Paraguaya de Ocupaciones (CPO)
Philippines - 2011 Philippine Standard Occupational Classification (PSOC)
Poland - Klasyfikacja zawodów i specjalności na potrzeby rynku pracy (KZiS)
Portugal - Classificação Portuguesa das Profissões (CPP/2010)
Qatar - Occupations
Romania - Clasificarea Ocupatiilor din Romania (COR)
Russian Federation - Общероссийский классификатор занятий (ОКЗ), Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР)
Sao Tome and Principe - Classicação das Profissões (CNP)
Serbia - Jedinstvena nomenklatura zanimanj / Klasifikacija zanimanja (JNZ / KZ)
Singapore - Singapore Standard Occupational Classification (SSOC 2010)
Slovakia -  Štatistická klasifikácia zamestnaní (ISCO-08)
Spain - Clasificación Nacional de Ocupaciones (CNO-11)
Suriname - International Standard Classification of Occupations (ISCO-08)
Sweden - Standard för svensk yrkesklassificering (SSYK)

Language is reflecting reality, and if the way construction work is organized is different in different countries, also the terms describing the workers will not be matchable.

Yes, there are similarities and differences. The Japanese top-level categories make a clear distinction between the wooden structure and other structures that I guessed at in my previous post. But it is visible there. The sub-items are what provide the ability to match. That is why there are 'crosswalks', a means like a document or table describing a mechanism or approach to translating, comparing or moving between standards, converting skills or content from one discipline to another. If you don't want to use the local one, there is an international one, and eventually someone can reconcile the local one.

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap. We usually try to create (not too) coarse classes/groups and use subtags to distinguish minor differences.

Classification schemes are always a Goldilocks Problem -  if it is too simple, it will grow awkwardly as it encounters edge cases and exceptions, it it is too complex, it will be ignored or even worse applied incorrectly. Usually you will see only three levels, and maybe a sparse fourth. The 'not too' qualifier mentioned is the issue. The trick is to define the hierarchy, and then assign the term to the proper level in the hierarchy. I would submit that domain experts coming to agreement worldwide over decades have had a better opportunity to refine these aspects than any small set of individuals in separate language communities ( for all I know, the Germans may have already solved this ).

FWIW, with regard to dictionaries, in the case of the misleading roofer description, it was copied exactly from the English wikipedia article on roofers, which is in itself not consistent there (mixes carpentry and roofing in the article).

My text was not copied from Wikipedia -  I only work from original authoritative source documents, in this case the U.S. Department of Labor, and the example I gave was an extract of an intermediate level, at the 'leaf' level ( click on the Details tab ) it goes down to the specific tools used: ... i.e. Hoists — Hydraulic swing beam hoists; Power hoists; Shingle ladder hoists; Trolley track hoist". Of course Wikipedia might be inconsistent, I occasionally use a Wikipedia reference if accurately gives a more general description than a more precise technical document.

That is a fairly extreme hierarchy, but needed for it's intended use - supporting crosswalks.
Employment-->Industry (Construction)-->Occupation ( Roofers)-->Details (Tools)-->Hoists ( Power, Swing, Trolley, etc.) ... most of the utility for ordinary people is in the top three levels.If I was asked to send a wood building 'roofer' to Japan, I will send a Log Peeler / Tile Setter instead, based on the tools and materials.  

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap.

There is no need for that. In my work with cross-national data, I reference the source hierarchy (and crosswalk if needed if I am integrating to someone else's work), fill in the two top levels, then add mine at the appropriate level. On the rare occasion, if there is a significant difference, I will invoke the fourth level - the next person using my classification then is automatically alerted why I used the wildly unexpected 'bark peeler' instead of 'roofer', I don't list all the tools and materials, just the two categories that made the distinction. If it is critical I might put the specific tool name.( 5th level ).

It is actually beneficial not to add everything. Over time, the entries actually in the data can be scanned and dichotomous keys created, where by asking a set of yes/no questions, one can get to an already used entry. I've seen school children get to exact species identification doing this, with no knowledge of the classification system itself. So things actually become easier for new users in the beginning.

There seems to be some sort of perception that standard classifications discourage diversity, but the opposite is true. As new concepts appear, they can be preserved and not force fit to the existing biases of previous categories - because there is a way to do that without disturbing the bulk of the existing base.

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?

Joseph Eisenberg
Of these two, “designation=*” is the best option, because it would be the same key in all countries.
On Fri, Dec 7, 2018 at 6:50 PM Eugene Podshivalov <[hidden email]> wrote:
I assume that the aforementioned issue with the official classification of settlement being deferent from the place tags values is faced in many countries.
So some common approach is needed here. There were many solutioned listed above, but it seems that only the following two are suitable for defining the local classification:
1.  in the respective category tag appended with language code, e..g. "place:RU="
2.  in the "designation" tag

пт, 7 дек. 2018 г. в 07:32, Michael Patrick <[hidden email]>:
you are right that there are dictionaries about this stuff, but you will have to have a basic idea in order to make use of them, particularly if English is not your native language, you might look up terms that you are familiar with, and might not be aware that you are missing another relevant term, or that the term is not a translation with more or less the same meaning but only loosely connected.

Trade in goods and services is international - most countries publish their classifications in their official language(s) and script. I looked looked at Mozambique at random, it's 520 pages of similar tables as the ISCO. The one that don't publish their own probably default to the ISOC standard, or like North Korea, don't play well with others.

(Sample extract ... some of the fonts for the Asian languages didn't copy properly)
Ireland - CSO Standard Employment Status Classification
Israel - (SCO) די יחלשמ לש דיחאה גוויסה
Italy -  Classificazione delle professioni (CP 2011)
Jamaica - Jamaica Standard Occupational Classification (JSOC 1991)
Japan - (JSOC)
Korea, Republic of -
Latvia - Profesiju klasifikators (PK)
Lithuania -  Lietuvos profesijų klasifikatorius (LPK)
Malaysia -  Malaysia Standard Classification of Occupations (MASCO 2008)
Maldives - International Standard Classification of Occupations (ISCO)
Mauritius - National Standard Classification of Occupations (NASCO-08)
Micronesia, Federated States of - International Standard Classification of Occupations (ISCO)
Mozambique - Classificação das Profissões de Moçambique revisão 2 (CPM Rev2)
Nauru - International Standard Classification of Occupations (ISCO)
Netherlands - Standaard Beroepenclassificatie 1992 (SBC 1992)
New Zealand - Australian and New Zealand Standard Classification of Occupations (ANZSCO)
Norway - Standard for yrkesklassifisering (STYRK-08)
Palestine -  (PSCO) ل د ط ا ير ا ا ف
Panama - Clasificación Nacional de Ocupaciones (CNO 2010)
Paraguay - Clasificación Paraguaya de Ocupaciones (CPO)
Philippines - 2011 Philippine Standard Occupational Classification (PSOC)
Poland - Klasyfikacja zawodów i specjalności na potrzeby rynku pracy (KZiS)
Portugal - Classificação Portuguesa das Profissões (CPP/2010)
Qatar - Occupations
Romania - Clasificarea Ocupatiilor din Romania (COR)
Russian Federation - Общероссийский классификатор занятий (ОКЗ), Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР)
Sao Tome and Principe - Classicação das Profissões (CNP)
Serbia - Jedinstvena nomenklatura zanimanj / Klasifikacija zanimanja (JNZ / KZ)
Singapore - Singapore Standard Occupational Classification (SSOC 2010)
Slovakia -  Štatistická klasifikácia zamestnaní (ISCO-08)
Spain - Clasificación Nacional de Ocupaciones (CNO-11)
Suriname - International Standard Classification of Occupations (ISCO-08)
Sweden - Standard för svensk yrkesklassificering (SSYK)

Language is reflecting reality, and if the way construction work is organized is different in different countries, also the terms describing the workers will not be matchable.

Yes, there are similarities and differences. The Japanese top-level categories make a clear distinction between the wooden structure and other structures that I guessed at in my previous post. But it is visible there. The sub-items are what provide the ability to match. That is why there are 'crosswalks', a means like a document or table describing a mechanism or approach to translating, comparing or moving between standards, converting skills or content from one discipline to another. If you don't want to use the local one, there is an international one, and eventually someone can reconcile the local one.

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap. We usually try to create (not too) coarse classes/groups and use subtags to distinguish minor differences.

Classification schemes are always a Goldilocks Problem -  if it is too simple, it will grow awkwardly as it encounters edge cases and exceptions, it it is too complex, it will be ignored or even worse applied incorrectly. Usually you will see only three levels, and maybe a sparse fourth. The 'not too' qualifier mentioned is the issue. The trick is to define the hierarchy, and then assign the term to the proper level in the hierarchy. I would submit that domain experts coming to agreement worldwide over decades have had a better opportunity to refine these aspects than any small set of individuals in separate language communities ( for all I know, the Germans may have already solved this ).

FWIW, with regard to dictionaries, in the case of the misleading roofer description, it was copied exactly from the English wikipedia article on roofers, which is in itself not consistent there (mixes carpentry and roofing in the article).

My text was not copied from Wikipedia -  I only work from original authoritative source documents, in this case the U.S. Department of Labor, and the example I gave was an extract of an intermediate level, at the 'leaf' level ( click on the Details tab ) it goes down to the specific tools used: ... i.e. Hoists — Hydraulic swing beam hoists; Power hoists; Shingle ladder hoists; Trolley track hoist". Of course Wikipedia might be inconsistent, I occasionally use a Wikipedia reference if accurately gives a more general description than a more precise technical document.

That is a fairly extreme hierarchy, but needed for it's intended use - supporting crosswalks.
Employment-->Industry (Construction)-->Occupation ( Roofers)-->Details (Tools)-->Hoists ( Power, Swing, Trolley, etc.) ... most of the utility for ordinary people is in the top three levels.If I was asked to send a wood building 'roofer' to Japan, I will send a Log Peeler / Tile Setter instead, based on the tools and materials.  

Additionally we are not going to add every single term that describes a profession as a tag, because there are synonyms and overlap.

There is no need for that. In my work with cross-national data, I reference the source hierarchy (and crosswalk if needed if I am integrating to someone else's work), fill in the two top levels, then add mine at the appropriate level. On the rare occasion, if there is a significant difference, I will invoke the fourth level - the next person using my classification then is automatically alerted why I used the wildly unexpected 'bark peeler' instead of 'roofer', I don't list all the tools and materials, just the two categories that made the distinction. If it is critical I might put the specific tool name.( 5th level ).

It is actually beneficial not to add everything. Over time, the entries actually in the data can be scanned and dichotomous keys created, where by asking a set of yes/no questions, one can get to an already used entry. I've seen school children get to exact species identification doing this, with no knowledge of the classification system itself. So things actually become easier for new users in the beginning.

There seems to be some sort of perception that standard classifications discourage diversity, but the opposite is true. As new concepts appear, they can be preserved and not force fit to the existing biases of previous categories - because there is a way to do that without disturbing the bulk of the existing base.

Michael Patrick

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
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?

Erkin Alp Güney
In reply to this post by Michael Patrick
Do they not have grade eight roofers in the US?

7.12.2018 01:38 tarihinde Michael Patrick yazdı:

>
>     great you name carpenters, because there were actually some
>     problems in the
>     past classifying people working with wood. ... Can you explain the
>     difference between a framer, a carpenter, a cabinet maker, a
>     joiner, a finish carpenter, a timberman, a ring builder, a jerry
>     man, a binder?
>
>
> There could only be a problem classifying trades if existing lexicons
> are ignored. At least in the U.S., currently, there are fairly exact
> definitions for trade classifications, down to the types of tools,
> specific materials, certification, and processes where required.
>
> Example: /"Grade 9 roofers must be fully skilled in installing new
> roofs. They must have the ability to apply the starter row of shingles
> to insure that they overlap properly and that they are securely
> fastened to the subsurface to eliminate possibility of leaks. On
> built-up roofs, they must be skilled in applying roofing felt, asphalt
> and gravel, or other topping material, and in sealing joints of
> roofing accessories with asphalt. In addition to work at the grade 7
> level, the grade 9 roofers must be able to install and repair the
> metal roofing accessories themselves, such as gravel guards,
> flashings, gutters, valleys, vents, pipes, and chimneys.They also must
> have the ability to cut and form metal accessories to meet roofing
> requirements, to fasten them to roofs with nails or screws, to solder
> metal joints, and to cut and shape shingles to fit around the
> accessories. In comparison with the grade 7 level, the grade 9 roofers
> also must be familiar with a greater variety of roofing materials and
> their uses and methods of installation. They must know how to apply
> wood, asbestos, slate tile, and composition shingles; metal roofing
> panels; roofing felt and asphalt. When required, they must be able to
> apply asbestos siding materials.In addition to the hand tools used at
> the grade 7 level, they must be skilled in the use of shingle cutters,
> metal snips and saws. "/
>
> International Open BIM systems standards ( Building Information
> Management, which covers the entire life cycle from natural site,
> through construction and operation, to demolition and site restoration
> ) have even finer grain of detail.
>
>     Some of them might be synonyms, some reflect regional differences
>     (e.g. AE
>     vs. BE)?
>
>
> Since the labor and materials supply chain is international, there are
> multi-lingual crosswalk tables between the U.S. and E.U., between the
> E.U. and the member countries.
>
> A casual observer might observe a job site during a pour, and classify
> the workers as 'concrete workers', when they are actually Formwork
> /Carpenters./
>
> Folksonomies <https://en.wikipedia.org/wiki/Folksonomy> like OSM have
> benefits, but as they expand, the downsides begin to matter, and there
> usually isn't an effective mechanism to refactor them.
>
> Sometimes the apparent complexity of these existing standards appear
> intimidating, but they all have a root, branches, and leaves, and one
> can select the level(s) of abstraction which are coincident with
> common language. i.e. in one place you can see what the differences
> /and similarities/ "... between a framer, a carpenter, a cabinet
> maker, a joiner, a finish carpenter, a timberman, a ring builder, a
> jerry man, a binder" are, and where your term lies in the hierarchy.
> Sometimes, the 'root' concept and groupings are not obvious.
>
> This also leaves room for reconciling it with other classifications -
> Japanese style carpentry roles are more or less orthogonal to Western
> style, more intensely aligned to product, the worker literally might
> select and fell the tree, mill that wood, and eventually carve it to
> shape in it's final position.
>
> It's a question, to a degree, of "re-inventing the wheel". There are
> already existing tagging schemes in the world ( some going back to the
> 1700's, from guilds and registries ). It might be worth a few minutes
> to seek those out, and adopt from those.
>
> 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
In reply to this post by Michael Patrick

thank you for the references to the specific standards. I’m going to look more into it. Problem is if these are hundreds of pages most people will not look the tags up ;-)



sent from a phone

On 7. Dec 2018, at 05:30, Michael Patrick <[hidden email]> wrote:

FWIW, with regard to dictionaries, in the case of the misleading roofer description, it was copied exactly from the English wikipedia article on roofers, which is in itself not consistent there (mixes carpentry and roofing in the article).

My text was not copied from Wikipedia -  I only work from original authoritative source documents, in this case the U.S. Department of Labor,


yes, I was referring to the OSM wiki, concerning the problems on the roofer page mentioned before in this thread, the wiki authors had copied from wikipedia. Sorry if this wasn’t clear.

Cheers, Martin 

_______________________________________________
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
 
From: Martin Koppenhoefer <[hidden email]>
thank you for the references to the specific standards. I’m going to look more into it. Problem is if these are hundreds of pages most people will not look the tags up ;-)

You're welcome, and I totally agree with your observation, especially considering the international basis of OSM. And thanks for even taking a passing interest in the topic. It is a "red-headed stepchild" sort of issue, and because it cuts across just about every community and portion of the OSM technology stack, and any effort to apply the known solutions would automatically generate a lot of animosity immediately, even if long-term it made life easier and more inclusive of local variation -  that is what happens outside of OSM, it's not specific to OSM.

I wouldn't expect individuals to look through hundreds of pages, any eventual solution would require a technology stack to assist the user, like a child using a botany key to find a species name in Latin in a couple of steps. And I respectfully submit that situation already exists, like with the user-defined 'amenity' tag (  9261items, 441 'pages' ). Addressing the situation rubs up against too many OSM culture themes, similar to large scale import or automatic edits. It is most likely easier to address outside of OSM, along with some sort of ODBL 'firewall' insulation ( like the NPS ). The NGA most likely does this sort of thing, with tools like Hootenanny
 
Do they not have grade eight roofers in the US?

True, to great extent, but the absence of an 8 in this case is not because of that. Actually there is a skills shortage crisis for all the trades in the U.S. ... the bulk of tradesmen in the country are retiring or near retirement in the next decade.

Somewhat off-topic for OSM, but it is a sort of 'tagging' schema.

The example text was pulled from the somewhat arcane U.S. Federal Wage Scales, where specific pay grades are then extracted to fit local conditions, especially trade union classifications - i.e. another area or skill might use 2,3,5,8,9.

Depending on the trade an apprenticeship program will range widely from 1 year to 6 years. Depending on the industry, the journeymen phase, it becomes even wider, for example the nuclear industry trades include "Basic Atomic & Nuclear Physics", "Heat Transfer & Fluid Flow"- in the U.K., I recall, you get a BEng in Nuclear Engineering out of some of the trade apprenticeships.  The Federal Grades are linear, and particular grades are selected that match specialization and trade for a given area, and that isn't always numerically 'linear'.

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
чт, 6 дек. 2018 г. в 04:17, Joseph Eisenberg <[hidden email]>:  
For example, in America we can call a waterway=stream a “brook”, “creek”, “run” and several other things. These waterways will be tagged waterway=stream or =river (depending on size) with name=“Bull Run”, =“Walker Creek”, =“Johnson’s Brook”, etc. 
We don’t use waterway=creek or waterway=run because there is no consistent difference between these. In fact in Standard British English a Creek is often a tidal channel in a salt marsh or mangroves.
There is difference between these types of water flows. You can read about it in this article

So in fact you are putting categories into names just because they do not match the OSM's tags.
In Russian for example we do not put "River" into river names at all whereas in English you do it always.
Another example is that in English you always say "Lake Baikal" whereas in Russian it is just "Байкал" (without the "lake" word).
In Russian we have very strict difference between a proper name and a common name. Whatever characterizes a group of objects is called common name, e.g. "street", "school", "hotel", "river", "stream", "creek" etc. Alsmost any proper name can be used without it's common name depending on the context, e.g. if you are discussing "Atlantic ocean" with your friend you can say just "Atlantic".

So this topic was raised as a suggestion to distinguish between proper and common names strictly to put only proper names into "name" field and common names into some other field taking into account that language specific common names very often differ from the generic categories adopted in OSM.
Without that distinction OSM cannot be called a true geospacial database because there are no fields which let you query data by it's real category (common name), you currently have to do that by analysing the "name" filed.
I understand that this would be a very big change but on the other hand it would open doors to utilizing OSM for absolutely any purpose, not just for maps rendering.

вс, 9 дек. 2018 г. в 03:38, Michael Patrick <[hidden email]>:
 
From: Martin Koppenhoefer <[hidden email]>
thank you for the references to the specific standards. I’m going to look more into it. Problem is if these are hundreds of pages most people will not look the tags up ;-)

You're welcome, and I totally agree with your observation, especially considering the international basis of OSM. And thanks for even taking a passing interest in the topic. It is a "red-headed stepchild" sort of issue, and because it cuts across just about every community and portion of the OSM technology stack, and any effort to apply the known solutions would automatically generate a lot of animosity immediately, even if long-term it made life easier and more inclusive of local variation -  that is what happens outside of OSM, it's not specific to OSM.

I wouldn't expect individuals to look through hundreds of pages, any eventual solution would require a technology stack to assist the user, like a child using a botany key to find a species name in Latin in a couple of steps. And I respectfully submit that situation already exists, like with the user-defined 'amenity' tag (  9261items, 441 'pages' ). Addressing the situation rubs up against too many OSM culture themes, similar to large scale import or automatic edits. It is most likely easier to address outside of OSM, along with some sort of ODBL 'firewall' insulation ( like the NPS ). The NGA most likely does this sort of thing, with tools like Hootenanny
 
Do they not have grade eight roofers in the US?

True, to great extent, but the absence of an 8 in this case is not because of that. Actually there is a skills shortage crisis for all the trades in the U.S. ... the bulk of tradesmen in the country are retiring or near retirement in the next decade.

Somewhat off-topic for OSM, but it is a sort of 'tagging' schema.

The example text was pulled from the somewhat arcane U.S. Federal Wage Scales, where specific pay grades are then extracted to fit local conditions, especially trade union classifications - i.e. another area or skill might use 2,3,5,8,9.

Depending on the trade an apprenticeship program will range widely from 1 year to 6 years. Depending on the industry, the journeymen phase, it becomes even wider, for example the nuclear industry trades include "Basic Atomic & Nuclear Physics", "Heat Transfer & Fluid Flow"- in the U.K., I recall, you get a BEng in Nuclear Engineering out of some of the trade apprenticeships.  The Federal Grades are linear, and particular grades are selected that match specialization and trade for a given area, and that isn't always numerically 'linear'.

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?

Marc Gemis
Alsmost any proper name can be used without it's common name depending
on the context, e.g. if you are discussing "Atlantic ocean" with your
friend you can say just "Atlantic".

I don't think this is true in all languages. We never do this e.g. for
the North Sea, which is Noordzee in Dutch. We never say "Noord". The
Dutch name for this sea, is never Noord, in whatever context. For some
other objects we might do drop it, e.g. churches (kerk in Dutch).

On the other hand if we talk about the "Atheneum van Berchem" , local
people will first drop the name of the village (Berchem) and just use
atheneum. They will not say "Berchem".

>
> So this topic was raised as a suggestion to distinguish between proper and common names strictly to put only proper names into "name" field and common names into some other field taking into account that language specific common names very often differ from the generic categories adopted in OSM.
> Without that distinction OSM cannot be called a true geospacial database because there are no fields which let you query data by it's real category (common name), you currently have to do that by analysing the "name" filed.

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. The purpose of tags is to indicate
what the thing is. One can add additional tags to the objects if one
wants, but changing the usage of the name field after more than 10
years would be very difficult to implement.

m,

_______________________________________________
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
вс, 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.

вс, 9 дек. 2018 г. в 14:10, Marc Gemis <[hidden email]>:
Alsmost any proper name can be used without it's common name depending
on the context, e.g. if you are discussing "Atlantic ocean" with your
friend you can say just "Atlantic".

I don't think this is true in all languages. We never do this e.g. for
the North Sea, which is Noordzee in Dutch. We never say "Noord". The
Dutch name for this sea, is never Noord, in whatever context. For some
other objects we might do drop it, e.g. churches (kerk in Dutch).

On the other hand if we talk about the "Atheneum van Berchem" , local
people will first drop the name of the village (Berchem) and just use
atheneum. They will not say "Berchem".

>
> So this topic was raised as a suggestion to distinguish between proper and common names strictly to put only proper names into "name" field and common names into some other field taking into account that language specific common names very often differ from the generic categories adopted in OSM.
> Without that distinction OSM cannot be called a true geospacial database because there are no fields which let you query data by it's real category (common name), you currently have to do that by analysing the "name" filed.

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. The purpose of tags is to indicate
what the thing is. One can add additional tags to the objects if one
wants, but changing the usage of the name field after more than 10
years would be very difficult to implement.

m,

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

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