Re: [Tagging] Which languages are admissible for name:xx tags?
On 25/3/20 10:30 pm, Martin Koppenhoefer wrote: Am Mi., 25. März 2020 um 10:27 Uhr schrieb Frederik Ramm mailto:frede...@remote.org>>: In my opinion, a name:xx tag should only be added if you can demonstrate that people natively speaking the living language xx are actually using this name for this entity. There are a few notable exceptions where a name in a "not so much living anymore" language might be quite useful and undisputed. I am thinking for example about Latin in Europe, northern Africa and the Middle East here. Currently we have about 7000 Latin names in the db. (there are some few instances that are probably disposable, e.g. it is strange to see latin names in Australia or Latin America https://taginfo.openstreetmap.org/keys/name%3Ala#map ) I tracked two of them down in Australia. It is used on the name of at least one state and the whole country. For the whole country it was entered in https://www.openstreetmap.org/changeset/17255604 for many countries from wikipedia. Over 6 years ago. Umm is that allowed, from wikipedia? The changeset does say the source is wikipedia. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Which languages are admissible for name:xx tags?
On 26/3/20 2:05 pm, Warin wrote: Some tags used at present are; alt_nameAyers Rock alt_name:cs Ayersova skála alt_name:en Ayers Rock nameUluṟu That's odd. The big red rock in the middle of Australia is called Uluru / Ayers Rock https://www.ntlis.nt.gov.au/placenames/view.jsp?id=10532 which would also be the name:en. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Refugee Site Location
Hi Joseph, Would segregation of data via a namespace tagging solution, as an alternative to using place=refugee_site, address these concerns regarding fuzzy "place" boundaries and the lack of observability (ie source based descriptive data)? Best regards, Stuart On Thu, Mar 26, 2020, 00:40 Joseph Eisenberg wrote: > In the previous proposal (Proposed features/Refugee Site Location) at > least 6 people who opposed the proposal mentioned the key "place=" was > not acceptable. > > Comments: > > "What about places that are de facto village/town but still > administered by UNHCR or another humanitarian organization or > governmental agency?" > > "...many long-term refugee camps have developed into a village or > town, where people live for many year. These permanent settlements > should be tagged as place=village or place=town, so if the tag for > refugee sites uses the same place=* key, then it is not possible to > use both at once." > > "A refugee camp or site is more like a landuse=residential area or an > amenity=social_facility, so perhaps consider using > landuse=refugee_site or amenity=refugee_site, or a subtag of > landuse=residential, like residential=refugee_site?" ( > > "Using the place tag for this causes problems in situations where the > distinction between a refugee camp and a town is vague. Is a > settlement of over 100,000 people, that's existed for 30 years and has > schools, hospitals and a graveyard a city or a camp? I think it should > be tagged as both. If it isn't then OSM will either not have some of > the biggest refugee camps mapped, or it not have some of the largest > towns/cities in the area mapped. Either would be a serious omission. > Because of that, the refugee site should be tagged outside of the > place tag." > > I'm disappointed that these concerns are being ignored. Instead, we > are told "''we recommend using only this key place=refugee_site and > not village/city since these sites have a status permanently different > to a “regular” populated place (the common legal framework of the > country doesn’t apply to it)''". That is ''not'' how we map places in > Openstreetmap. > > See "Good_practice" "Don't map your local legislation, if not bound > to objects in reality" and "Verifiability": we don't map what a > country claims to be true, but what is actually real. If a "camp" is a > 30 year old settlement with >10,000 residentis, plus shops, clinics, > schools, places of worship etc, then it is a place=town, no matter > what the local government says. > > Of course it can also be a refugee_site in a way, so the tag for a > refugree site should be something that does not conflict with > place=village/town. > > Also, is there already an Import page set up by CartONG for the > proposal to import this info from the UNHCR database? > > -- Joseph Eisenberg > > On 3/25/20, Manon Viou wrote: > > Hello, > > > > The proposed feature place=refugee_site to provide a way for mapping > places > > sheltering refugees and/or internally displaced persons fleeing the > effects > > of a natural disaster or a political crisis for example has already been > > debated and voted on from 30-01-2020 to 17-03-2020. It was then rejected > by > > a narrow margin on the final day of voting. > > > > We have since tried to answer to the concerns and comments received, and > to > > adapt and simplify the proposed tag to map refugee site location. > > > > We would like to discuss this tag with all interested people again during > > the Request For Comment phase, open until Friday, April 3rd. Thank you ! > > > > Please visit the new feature proposal wiki page here : > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location_2 > > > > Best regards, > > Manon > > > > [image: CartONG- Humanitarian mapping and information management] > > > > Manon Viou > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Which languages are admissible for name:xx tags?
Am Mi., 25. März 2020 um 15:23 Uhr schrieb Joseph Eisenberg < joseph.eisenb...@gmail.com>: > > "if the name is otherwise regarded correct by mainstream media or a > language authority." > > In that case, please add it to wikidata with a reference, but it would > not be appropriate for Openstreetmap. > > Unlike wikipedia and wikidata, which are based on references and > citations to "authoritative" sources, Openstreetmap has always been > designed as a primary source: we map real, current features which you > can visit in person. with some notable exceptions (e.g. many administrative boundaries), and maybe names in foreign languages? This is how I would interpret this thread here, discuss whether we welcome names in languages that aren't spoken at the place, and if yes, whether there are limits to it. We have seen that in OSM exceptions can be made for any rule, still, most of the time we adhere to them. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Key:locked
Some tags have been approved which allow for adding such details under the barrier:-tag, e.g. https://wiki.openstreetmap.org/wiki/Key:barrier:personnel This is the original proposal: https://wiki.openstreetmap.org/w/index.php?oldid=840159#Combinations_.2F_Subtags Unfortunately, the other additional tags are not better documented yet. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Which languages are admissible for name:xx tags?
Names in OSM map is to show the world reader what each objects are. Unlike Wikipedia and Wikidata, OSM map everything on the ground. Let assume the world's common language is now priparaish, and English is now only spoken by a small insignificant African tribe, and is also the only language in the world that use latin script. And you as a member of the English-speaking tribe, trying to navigate the map of the world on the OpenStreetMap, and see objects everywhere outside the area of your little tribe are in the format of လူတိုင်းသည် တူညီ လွတ်လပ်သော , do you think you would be able to read and use the map? If you heard a news which said a terrorist attack occurred at Ketsumisomewhere in local language, turn to OpenStreetMap and search for the place name, and then find out there are no Ketsumisomewhere in the world because your language is deemed spoken by too few to be worth including into OSM and the only name listed in OSM for the place is केट्सुमीसोममेरे, do you think it is going to be helpful? According to OpenStreetMap's mission statement, one of the core value of OSM is "We want OSM data to be used as widely as possible". You cannot use OSM data as widely as possible without providing the name of all different features in all different languages, even if some languages might only be spoken by relatively few people, they are still human that can digest OSM data. Do you think it is a good idea not to translate the name of an "Nofoaga faʻapitoa mo fesoasoani faʻafuaseʻi" object into English because no one speak English at the place it's established even thought people from aroind the world travelling there who speak English might come and seek help at the emergency assistance center? > If an Indonesian mapper adds name:id=* tags to every village in northern Finland, how is anyone to confirm that they are right or wrong? They are to be confirmed by other Indonesian mappers. 在 2020年3月25日週三 22:23，Joseph Eisenberg 寫道： > > "if the name is otherwise regarded correct by mainstream media or a > language authority." > > In that case, please add it to wikidata with a reference, but it would > not be appropriate for Openstreetmap. > > Unlike wikipedia and wikidata, which are based on references and > citations to "authoritative" sources, Openstreetmap has always been > designed as a primary source: we map real, current features which you > can visit in person. > > I agree that names in fictional languages should not be added to > name: tags, nor any name which cannot possibly be confirmed to be > true or false by local mappers. > > If an Indonesian mapper adds name:id=* tags to every village in > northern Finland, how is anyone to confirm that they are right or > wrong? > > -- Joseph EIsenberg > > On 3/25/20, Jyri-Petteri Paloposki wrote: > > On 25.3.2020 12.58, Christoph Hormann wrote: > >> In terms of our traditional values and principles active use of the name > >> is not the necessary criterion, it is verifiable local knowledge. Like > >> with any kind of names practical verification of names would be > >> possible by inquiring about the name to people locally. This > >> essentially means the following practical requirements: > >> > >> * there being a sufficient number of people present locally that > >> speak/write the language in question. Those don't have to be people > >> living there, it can also be visitors. > >> * these people knowing the name in said language - being able to look it > >> up on some external source does not count, that is wikipedia > >> verifiability, not OSM verifiability. > >> * these people largely consistently agreeing on the same name. > > > > I slightly disagree with this one. IMO a name in a foreign language > > would be admissible if it is recognised by native speakers of the > > language either back home or in the local community OR if the name is > > otherwise regarded correct by mainstream media or a language authority. > > > > I recently checked if the foreign cities listed in the Finnish Wikipedia > > as having a specific Finnish name were correct in OSM. I stumbled upon > > Yokohama, for which I didn't know there's a Finnish wording (Jokohama). > > However once I saw it, it definitely is understandable and clearly > > Finnish. It is also used by the Finnish mainstream media[1] and endorsed > > by the Institute for the Languages of Finland[2], which is the authority > > responsible for recommendations concerning the Finnish language. Still, > > if asked, I wouldn't have instantly been able to recognise the name as > > correct despite being a native Finnish speaker. > > > > 1) https://yle.fi/uutiset/3-10956002 > > 2) http://www.kielitoimistonohjepankki.fi/haku/jokohama/ohje/633 > > > > Best regards, > > -- > > Jyri-Petteri Paloposki > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > ___ > Tagging mailing l
Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?
I was blissfully unaware of the issues involved in creating a bilingual map (dual labeled in the local language and in my language) until I actually tried to create one. Most objects in OSM do not have name: tags for non-local languages and it is unreasonable to expect that every named village, town, river and stream in some far off land have a name: value for your language. Especially since the vast majority of the values would be transliterations which we would like to avoid [1]. In my case I thought it would be useful to have a printed map with features showing the local name in the local language and script along with an English version of the name. If the name:en existed use it. If not then use an automatically generated phonetic transliteration. The problem I ran into was you need to know the language used in the name tag [2] to know what rules to use for transliteration. As I understand it, there are several ways to determine the language and there has been at least a couple of proposals or tagging list discussions on this topic but with no consensus. The ones that come to mind for me are: 1. The current situation where the there is no formal method. If one follows the wiki recommendation [3] that the name value be duplicated into a name: tag then the language can be determined in many cases. Unfortunately this fall apart if the same spelling and alphabet are used with different pronunciations. An example that comes to mind would be for the city of Paris where there are several name: tags that exactly match the name value. Which one should be picked? The pronunciations are different in different languages, if you are going to attempt automatic transliteration you would like to correctly pick French as the language to transliterate from. So the current situation is not ideal: This wiki recommendation is seldom followed. If it is then some mappers are going to decide that the “duplicates” are undesirable and remove them. And, if followed there are fairly common cases where it still is not possible to determine the language. 2. Create a scheme where a default language can be set on boundaries as has been suggested by Joseph Eisenberg [4]. This has the advantage that relatively few objects need to be tagged, for example it might be possible that only one tag could be used to cover the continental United States. But it falls apart for features that are on the boundary between multiple language areas (Mediterranean Sea for example) and for areas that are multilingual (Wales for example). In addition, it seems that any type of “we should add a default for an administrative area” proposal that has come up here has been rejected or “bike shedded” into oblivion. 3. Drop the name tag altogether and add a name formatting tag [5]. As I understand it, the formatting specification would be used to take one or more name: values and specify how they should be combined to create a name for display purposes. Migrating to this scheme could be hard and may only be possible if a default name format could be specified for an area as in the default language scheme in 2 above. Even if a default mechanism could be agreed to, the magnitude of changing all the name=* to name:=* for even a relative small monolingual area would be a big task if automated changes are not used. Finally, it does not resolve the issue of ambiguity in the language used. 4. Create a new tag explicitly specifying the language used in the name tag. This has the same disadvantage as the current wiki recommendation for duplicating the name value into a name: value in that it has to be done on each object. But it does have the advantage that it there is no ambiguity in showing the language of the name tag value and it can be rolled out a little at a time. 5. ??? There are probably other schemes that have been proposed that I haven’t noticed. Thoughts? —Tod [1] https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration [2] https://wiki.openstreetmap.org/wiki/Multilingual_names#Issues [3] https://wiki.openstreetmap.org/wiki/Names#Repeating_name_with_language_specific_tag [4] https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format [5] http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/ > On Mar 25, 2020, at 11:25 PM, Joseph Eisenberg > wrote: > > That's why I previously proposed a tag like default_language=* which > could be added to features and boundaries. See > https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format > > Unfortunately that was not approved. It's a confusing topic, many of > the people who opposed the proposal seemed to think it would do > something else. > > -- Joseph Eisenberg > signature.asc Description: Message signed with OpenPGP ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?
sent from a phone > On 26. Mar 2020, at 23:54, Tod Fitch wrote: > > 2. Create a scheme where a default language can be set on boundaries as has > been suggested by Joseph Eisenberg [4]. This has the advantage that > relatively few objects need to be tagged, for example it might be possible > that only one tag could be used to cover the continental United States. But > it falls apart for features that are on the boundary between multiple > language areas (Mediterranean Sea for example) these could/should be outside of the default language areas as there isn’t a default language. There are also voices to omit name tags without language code in these “international” areas. > and for areas that are multilingual (Wales for example). you could state that several languages are the default (even give hints about how they are formatted, provided there are multiple names in one standard name tag, something like ”de / it” (or including language and script)), or you’d have overlapping areas for languages (and maybe scripts) > In addition, it seems that any type of “we should add a default for an > administrative area” proposal that has come up here has been rejected or > “bike shedded” into oblivion. the language areas must not necessarily be administrative areas (although it would clearly simplify adding and maintaining them), for example there could be a single (multi)-polygon for France and part of Belgium. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?
Note that there were several rejected proposals before mine, including these two by Sommerluk: https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name (name:language=*) https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information (language:*=*) And note that after the last proposal, another user added default_language to most admin_level=2 features, though it hasn't been used yet for smaller areas as would be needed (and the description about mullti-lingual areas is confusing): https://wiki.openstreetmap.org/wiki/Key:default_language -- Joseph Eisenberg On 3/27/20, Tod Fitch wrote: > I was blissfully unaware of the issues involved in creating a bilingual map > (dual labeled in the local language and in my language) until I actually > tried to create one. > > Most objects in OSM do not have name: tags for non-local languages and > it is unreasonable to expect that every named village, town, river and > stream in some far off land have a name: value for your language. > Especially since the vast majority of the values would be transliterations > which we would like to avoid [1]. > > In my case I thought it would be useful to have a printed map with features > showing the local name in the local language and script along with an > English version of the name. If the name:en existed use it. If not then use > an automatically generated phonetic transliteration. The problem I ran into > was you need to know the language used in the name tag [2] to know what > rules to use for transliteration. > > As I understand it, there are several ways to determine the language and > there has been at least a couple of proposals or tagging list discussions on > this topic but with no consensus. The ones that come to mind for me are: > > 1. The current situation where the there is no formal method. If one follows > the wiki recommendation [3] that the name value be duplicated into a > name: tag then the language can be determined in many cases. > Unfortunately this fall apart if the same spelling and alphabet are used > with different pronunciations. An example that comes to mind would be for > the city of Paris where there are several name: tags that exactly match > the name value. Which one should be picked? The pronunciations are different > in different languages, if you are going to attempt automatic > transliteration you would like to correctly pick French as the language to > transliterate from. So the current situation is not ideal: This wiki > recommendation is seldom followed. If it is then some mappers are going to > decide that the “duplicates” are undesirable and remove them. And, if > followed there are fairly common cases where it still is not possible to > determine the language. > > 2. Create a scheme where a default language can be set on boundaries as has > been suggested by Joseph Eisenberg [4]. This has the advantage that > relatively few objects need to be tagged, for example it might be possible > that only one tag could be used to cover the continental United States. But > it falls apart for features that are on the boundary between multiple > language areas (Mediterranean Sea for example) and for areas that are > multilingual (Wales for example). In addition, it seems that any type of “we > should add a default for an administrative area” proposal that has come up > here has been rejected or “bike shedded” into oblivion. > > 3. Drop the name tag altogether and add a name formatting tag [5]. As I > understand it, the formatting specification would be used to take one or > more name: values and specify how they should be combined to create a > name for display purposes. Migrating to this scheme could be hard and may > only be possible if a default name format could be specified for an area as > in the default language scheme in 2 above. Even if a default mechanism could > be agreed to, the magnitude of changing all the name=* to name:=* for > even a relative small monolingual area would be a big task if automated > changes are not used. Finally, it does not resolve the issue of ambiguity in > the language used. > > 4. Create a new tag explicitly specifying the language used in the name tag. > This has the same disadvantage as the current wiki recommendation for > duplicating the name value into a name: value in that it has to be done > on each object. But it does have the advantage that it there is no ambiguity > in showing the language of the name tag value and it can be rolled out a > little at a time. > > 5. ??? There are probably other schemes that have been proposed that I > haven’t noticed. > > Thoughts? > > —Tod > > [1] https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration > [2] https://wiki.openstreetmap.org/wiki/Multilingual_names#Issues > [3] > https://wiki.openstreetmap.org/wiki/Names#Repeating_name_with_language_specific_tag > [4] > https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format > [5] > http://blog.im
Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)
Hi all, The line_management=* proposal vote will be open starting on next Monday. https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management Clarifications and improvements have been made as follow : * Focus on power only and remove telecom usecase. Proposed terminology is generic enough to be used in telecom sector in a further proposal to give better solutions to tag telecom supports. * Remove line_management=loop and consider them as line_management=branch Proposed key has been used by 6 people on ~450 features already without big problems it seems. Feel free to raise concerns or wait next week to vote on the document. All the best François Le jeu. 9 janv. 2020 à 01:08, François Lacombe a écrit : > Hi all, > > This proposal is still in RFC and may be voted in a couple of weeks as > evaluation shown no issue so far, at least on transmission power lines. > line_management tag is used carefully for testing. > Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058 > > Nevertheless it's an opportunity to review the branch:type tag replacement > with line_management=* > > i'm still looking for an appropriate illustration for two values examples: > * line_management=cross (two or more lines with different directions > sharing the same support without connecting) > * line_management=loop (two or more lines coming from the same direction > are connected as to mock some of them) > > Feel free to propose and complete if you find corresponding situations on > ground > > Thanks in advance > > François > > Le sam. 26 oct. 2019 à 20:59, François Lacombe > a écrit : > >> Hi all, >> >> After the review of line_attachment key this summer and Karlsruhe >> hackweekend at Geofabrik headquarters last week, let me introduce the >> second stage of tower:type key cleaning project for power lines. Great time >> has been spent on discussing and finding relevant situations. >> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management >> >> It's now about the arrangement of power lines around their supports: how >> the lines branch, split, transpose or terminate. >> As current tagging (without line_management) still collides with any >> tower building function, the line_management key may be a solution to strip >> unrelated values from tower:type. >> >> I've published a diary entry to give more explanations >> https://www.openstreetmap.org/user/InfosReseaux/diary/391058 >> >> I'd draw your attention to the conclusion : >> "Mapping utility supports like power towers or telecom poles is a >> worldwide challenge. For instance in France, professionals including >> operators and contractors rolling out overhead telecom cables are currently >> looking for approx. 16 millions missing shared power poles that weren’t >> mapped in operational GIS. There’s no doubt updating OSM can help." >> There's no short term risk of importing massive data, at least. >> >> This proposal is a first try and may cause worries about some local >> concerns. RFC is here to solve this prior to vote anything. >> We have to focus on simple situations to begin with to adopt the right >> semantic. More complex cases will be added step by step. >> Feel free to open a topic in Talk page. >> >> All the best >> >> François >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)
The explanation of line_management=branch is not very clear:
"==Loops are actual branches==
Former undocumented key {{Tag|branch:type}} had a value for
connections between several power lines coming from the same
direction: ''loop''.
"It is proposed to consider them as branches due to
[http://osm.janos-koenig.de/IMG_0046.JPG such situations] where 3
lines connect to the same support and look like a loop but shouldn't
be described this way."
What does this mean?
Another part says:
tower:type=branch ( + branch:type=loop) -> to be replaced by
line_management=branch
"Two or more independent circuits are connected in the same direction
to maintain a dead part of the network under a positive voltage"
What's a dead part of the network? What do you mean by positive
voltage, can voltage be negative?
Also, it's mentioned that tower:type=crossing (where a power line
crosses a river or canyon) should be replaced by height=* + designe=*
where "A support is significantly higher and stronger to allow a line
to cross an obstacle like rivers"
Are you proposing any new values of "design=*" for this, or should
existing values be used?
-- Joseph Eisenberg
On 3/27/20, François Lacombe wrote:
> Hi all,
>
> The line_management=* proposal vote will be open starting on next Monday.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>
> Clarifications and improvements have been made as follow :
> * Focus on power only and remove telecom usecase. Proposed terminology is
> generic enough to be used in telecom sector in a further proposal to give
> better solutions to tag telecom supports.
> * Remove line_management=loop and consider them as line_management=branch
>
> Proposed key has been used by 6 people on ~450 features already without big
> problems it seems.
>
> Feel free to raise concerns or wait next week to vote on the document.
>
> All the best
>
> François
>
> Le jeu. 9 janv. 2020 à 01:08, François Lacombe
> a écrit :
>
>> Hi all,
>>
>> This proposal is still in RFC and may be voted in a couple of weeks as
>> evaluation shown no issue so far, at least on transmission power lines.
>> line_management tag is used carefully for testing.
>> Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>>
>> Nevertheless it's an opportunity to review the branch:type tag
>> replacement
>> with line_management=*
>>
>> i'm still looking for an appropriate illustration for two values
>> examples:
>> * line_management=cross (two or more lines with different directions
>> sharing the same support without connecting)
>> * line_management=loop (two or more lines coming from the same direction
>> are connected as to mock some of them)
>>
>> Feel free to propose and complete if you find corresponding situations on
>> ground
>>
>> Thanks in advance
>>
>> François
>>
>> Le sam. 26 oct. 2019 à 20:59, François Lacombe
>>
>> a écrit :
>>
>>> Hi all,
>>>
>>> After the review of line_attachment key this summer and Karlsruhe
>>> hackweekend at Geofabrik headquarters last week, let me introduce the
>>> second stage of tower:type key cleaning project for power lines. Great
>>> time
>>> has been spent on discussing and finding relevant situations.
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>>>
>>> It's now about the arrangement of power lines around their supports: how
>>> the lines branch, split, transpose or terminate.
>>> As current tagging (without line_management) still collides with any
>>> tower building function, the line_management key may be a solution to
>>> strip
>>> unrelated values from tower:type.
>>>
>>> I've published a diary entry to give more explanations
>>> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>>>
>>> I'd draw your attention to the conclusion :
>>> "Mapping utility supports like power towers or telecom poles is a
>>> worldwide challenge. For instance in France, professionals including
>>> operators and contractors rolling out overhead telecom cables are
>>> currently
>>> looking for approx. 16 millions missing shared power poles that weren’t
>>> mapped in operational GIS. There’s no doubt updating OSM can help."
>>> There's no short term risk of importing massive data, at least.
>>>
>>> This proposal is a first try and may cause worries about some local
>>> concerns. RFC is here to solve this prior to vote anything.
>>> We have to focus on simple situations to begin with to adopt the right
>>> semantic. More complex cases will be added step by step.
>>> Feel free to open a topic in Talk page.
>>>
>>> All the best
>>>
>>> François
>>>
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?
On 27/03/2020 00.51, Martin Koppenhoefer wrote: sent from a phone On 26. Mar 2020, at 23:54, Tod Fitch wrote: 2. Create a scheme where a default language can be set on boundaries as has been suggested by Joseph Eisenberg [4]. This has the advantage that relatively few objects need to be tagged, for example it might be possible that only one tag could be used to cover the continental United States. But it falls apart for features that are on the boundary between multiple language areas (Mediterranean Sea for example) these could/should be outside of the default language areas as there isn’t a default language. There are also voices to omit name tags without language code in these “international” areas. and for areas that are multilingual (Wales for example). you could state that several languages are the default (even give hints about how they are formatted, provided there are multiple names in one standard name tag, something like ”de / it” (or including language and script)), or you’d have overlapping areas for languages (and maybe scripts) In addition, it seems that any type of “we should add a default for an administrative area” proposal that has come up here has been rejected or “bike shedded” into oblivion. the language areas must not necessarily be administrative areas (although it would clearly simplify adding and maintaining them), for example there could be a single (multi)-polygon for France and part of Belgium. As it was said several times, Belgium already has language areas as this French Community boundary that has been chosen to be political because there is nothing more suitable. Also, there is a Proposed features/Defaults and if we clutch the two together we have default languages. However, this Defaults proposal has been left stranded because almost no one see its importance, because it's highly misunderstood and because it should be better explained. Important because it would stop OSM data to be outside of the OSM database. Example: Flanders (north of Belgium) changed their speed limit from Belgium's 90 to 70 km/h. With a working Defaults this would have been a one number or so change of the OSM data. Without one, it would have been changing the local data of many routers, GPSes and such. Conclusion, Flanders now tags very road speed explicitly and don't use defaults any more. All the best, André. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
