[talk-cz] WeeklyOSM CZ 458

[Tom Ka]

Ahoj, je dostupné vydání 458 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/11987

* Upgrade doplňku Tracer pro JOSM.
* Něco jako RÚIAN pro Slovensko?
* Neverifikovatená geometrie.
* Mapování Heidelbergu před SotM.
* Grab v Thajsku.
* Co přesně znamená park?
* Svobodný adresář firem z OSM.
* Úklid OSM wiki.
* Novinky v MapSwipe.
* Mapa hradů Švýcarska.
* Londýnský maraton a OSM dlaždice.
* JOSM a změna licence Javy.

Pěkné počtení ...

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

pá 10. 5. 2019 v 18:57 odesílatel Spratek  napsal:
> Zdravím,
> souhlas Lesů ČR mám, pokud mi někdo řekne kam ho mam poslat, tak ho tam pošlu.

ahoj, pokud mas jen elektronicky, staci sem nebo na
spo...@openstreetmap.cz. Pokud mas papirove, posli prosim mne na
adresu:

Tomáš Kašpárek
Na klínku 803/30
644 00 Brno

a ja zalozim do dokumentace spolku. Dalsi moznosti je predat osobne v
Praze, Brně nebo Ostrave(FM) clenovi rady spolku.

Bye

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Übersetzung MAPS.ME

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 12:35, Andreas Schmidt  
> wrote:
> 
> Ich habe das Wort 'Buchmacher' noch nie gehört. Spontan hätte ich einen
> Handwerksberuf vermutet.
> 'Wettbüro' ist hier in Norddeutschland m.E. viel gebräuchlicher. Synonym
> nutze ich 'Sportwetten' (als Gebäudebezeichnung).


Buchmacher und “Wettbüros” haben evtl. leicht unterschiedliche Bedeutungen? 
Sportwett“büros“ sind wohl die meisten der bookmaker getaggten Dinge, aber 
„Buchmacher“ ist allgemeiner und schließt mehr ein. Sportwetten könnte 
vielleicht in iD ein alias sein, ggf. aber auch noch mit zusätzlichem tag 
(spezifisch „Sportwetten“)?


Vor ein paar Jahren wurde der „Glücksspielbereich“ strukturiert und besser 
dokumentiert, und es funktioniert schon ganz gut, jedenfalls gibt es in dem 
Bereich auch noch shop=lottery, aber ich habe weder in Deutschland noch in 
Italien kaum jemals einen shop gesehen, der nur Lotto gemacht hat, entweder 
sind das Zeitungsläden, Tankstellen, ggf. Tabak oder Bars, eigentlich bräuchte 
man hierzulande eine property.

Gruß, Martin 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] Tag presenti in Italia

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 22:08, mbranco2  wrote:
> 
> Voglio però cogliere l'occasione per fare una proposta, e cioè regolamentare 
> in generale le "modifiche massive", che siano per sistemare macro-errori 
> evidenti ma anche per proporre di standardizzare (=normalizzare) un certo 
> modo di taggare.
> Un po' come per gli import, anche se con un iter un po' più blando.
> 
> Lo ritengo opportuno perché penso sia da salvaguardare lo "spirito" di OSM 
> che consente ed ammette uno "stile personale" di mappatura, così come 
> permette che una certa caratteristica sia mappabile in più modi tra loro 
> alternativi (anche se per deformazione professionale sono sensibile 
> all'esigenza di normalizzazione/standardizzazione dei dati).


si, per fortuna questa attività è già regolamentato, simile agli edit 
guidelines ci sono quelli per gli edit “semi-automatici”.
Purtroppo spesso non sono rispettati...

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Pilone

[Nogaro]

Se non ha significato religioso, la  mapperei come man_made=cairn

 

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcairn

 

Assomiglia a questo:

 

https://en.wikipedia.org/wiki/File:BorderPost272_-_Norway_and_Sweden.jpg

 

che su wikipedia è usato per illustrare un cairn.

 

Alberto

 

From: solitone  
Sent: 10 May 2019 19:01
To: openstreetmap list - italiano 
Subject: [Talk-it] Pilone

 

A fianco di un un sentiero in montagna ho incontrato questo:

 



 

 Si chiama Pilone Gardetta. E’ una specie di ometto di pietre evoluto, l’anello 
di congiunzione tra gli ometti e piloni e le edicole votive. In montagna ce ne 
sono diversi.

 

Come mapparlo? Con il classico historic=wayside_shrine? 

 

 

 

 

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Yuri Astrakhan]

On Fri, May 10, 2019 at 3:39 PM Yves  wrote:

> Some validation tools, like Osmose, make great efforts to maintain a
> 'false positive' database.
>

If the same validation is done by multiple tools, they need to share the
"false positive" data, otherwise only one tool would know not to change
something, while another tool will encourage the user to make the same
mistake.

So we either have to set up an OSM shadow database that contains all
exceptions, e.g. "object  is exempt from validation ", or this data
should be stored in the object itself, which seems to be a far more robust
approach (same data store allows data consistency / versioning / user
management / tracking / consistency between tools / same processing
pipeline / ...).

If the objection to this is that users don't want to see junk data, I agree
-- but we could simply dedicate a key namespace to validations, and hide it
by default in JOSM and iD.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] TfL Cycling Infrastructure Database

[Dave F via Talk-GB]

This looks very interesting, well worth investigating, but could any 
comments be posted here please -  We get notifications, they're recorded 
& date sorted. I've yet to see a wiki discussion that doesn't become 
incoherent after a dozen posts.

.
DaveF

On 10/05/2019 17:03, Jez Nicholson wrote:

Firstly, exceptionally pleased that TfL see OSM as *the* major people
access cycling data :D

Their data is highly accurate, and there's definitely going to need to be
some clever conflation tooling. Bike stands are fine, but advance stop
lines, etc. are specialist subjects in my book. I'm sightly overawed by the
quantity and am unsure whether volunteers are going to be able to get
through it, but again that is something you'll be talking about in your
report, no? There would need to be some tool development regardless of who
does the conflation.

Also, you could start some discussion in the talk tab of that wiki page if
there's anything that needs thrashing out.

...and now I know what a "Sheffield" bike stand is :)

Regards,
   Jez

On Fri, May 10, 2019 at 3:42 PM Martin Lucas-Smith - CycleStreets <
list-osm-talk...@cyclestreets.net> wrote:



Transport for London (TfL) have created a new database of cycling
infrastructure, containing 240,000 assets, covering all of Greater London.

This groundbreaking database contains every cycle infrastructure asset
within Greater London, including assets on and off-carriageway. The assets
surveyed are: cycle parking; signals; signage; traffic calming measures;
restricted points (e.g. steps); advanced stop lines; crossings; cycle
lanes/tracks; and restricted routes (e.g. pedestrian only routes).

TfL is keen to make this available to the OpenStreetMap community under a
compatible open license, to ensure maximum use of the CID. TfL is also
potentially willing to consider tool development to help facilitate
sensitive merging in of this data.

There is a new Wiki page, giving full details, at:
https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database


Demonstrator map:
-

A demonstrator map, for the purposes only of evaluation by the OSM
community at this stage, has been created by CycleStreets.

This demonstrator map contains only one of the 25 areas that have been
surveyed.

We are specifically seeking comments on data quality and usefulness of
this
data from the OSM community. Initial analysis by CycleStreets is that the
data is of excellent quality, and very suitable for conflation into OSM,
to
increase both comprehensiveness and metadata quality.

https://tflcid.cyclestreets.net/
(Use the controls on the right to change feature type.)

Usage notes: The controls on the right of the map allow the different
feature types to be selected. The OSM layer (available at zoom level 19+)
also provides a live feed from the OSM API, to enable quick comparisons.
The two photos of each asset are in the process of being supplied; those
already available and cleared in GDPR terms are included in the popup.

It is stressed that at this point, no permission is given for re-use of
the
data in any way, but TfL strongly intends to make this available in
future.
All 25 areas would be covered in the final data release, not merely the
one
shown currently in the demonstrator map.


Feedback is very strongly encouraged, as soon as possible. What are
people's thoughts?


Martin, **  CycleStreets - For Cyclists, By Cyclists
Developer, CycleStreets **  https://www.cyclestreets.net/


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Tag presenti in Italia

[mbranco2]

Bravo Ale,

hai scoperchiato un vaso di Pandora a cui penso da parecchio, vediamo se
riusciamo a trovare una quadra.

Finché si tratta di correggere errori di battitura, non c'è discussione e
benemerito chi la fa.
Anche eliminare la spazzatura-rumenta è opera meritoria, e dio solo sa
quanta ce n'è in OSM...

Voglio però cogliere l'occasione per fare una proposta, e cioè
regolamentare in generale le "modifiche massive", che siano per sistemare
macro-errori evidenti ma anche per proporre di standardizzare
(=normalizzare) un certo modo di taggare.
Un po' come per gli import, anche se con un iter un po' più blando.

Lo ritengo opportuno perché penso sia da salvaguardare lo "spirito" di OSM
che consente ed ammette uno "stile personale" di mappatura, così come
permette che una certa caratteristica sia mappabile in più modi tra loro
alternativi (anche se per deformazione professionale sono sensibile
all'esigenza di normalizzazione/standardizzazione dei dati).

Faccio un esempio (ne avevamo già parlato tempo fa ma a volte giova
ripetere): a me non piace che nel name di un elemento ci sia anche il "cosa
è", quindi per me il fiume più lungo d'Italia (che è taggato con
waterway=river) è giusto che abbia name=Po e non name=Fiume Po. Ma allora
perchè il Sesia ha name=Fiume Sesia ?
Se fate una ricerca in overpass, vedrete che parecchi fiumi e torrenti
hanno il name che inizia con "Fiume" o "Torrente".
Stessa cosa per le montagne (natural=peak): magari che il name inizi con
"Monte" lo lascerei per il Monte Bianco ed il Monte Rosa, ma ci sono
tantissime altre cime che hanno il name che inizia con "Monte" (chiedo ai
valdostani: lo Zerbion è più giusto chiamarlo "Monte Zerbion"?)

Bene, io la penso così però sbaglierei di grosso se mi mettessi a
modificare a tappeto tutti i name dei fiumi/torrenti o delle montagne
italiane in base a come la penso io, senza una discussione con la
comunità...

Ecco quindi la proposta (vale tanto per la sistemazione di macro-errori
evidenti quanto per le "normalizzazioni" potenzialmente soggette ad
opinioni diverse):
creare una pagina "Modifiche massive" nella Wiki  con una tabella che
riporti
- Titolo della proposta
- Nickname del/i proponente/i
- Data proposta
- Area interessata (tutta l'Italia, una regione, una provincia...)
- Link alla discussione in mailing list
- Descrizione della proposta (se poche righe, altrimenti link ad una
apposita pagina sempre nella wiki)
- Data di esecuzione

La descrizione della proposta (o l'apposita pagina) dovrebbe contenere
un'analisi dei tag attuali, come verrebbero modificati, e con quali
strumenti sarebbe eseguita la modifica.

Ok, ho lanciato il sasso nello stagno, se considerate l'argomento degno
d'interesse sono disponibile ad impostare un template nella wiki.

Buona serata,
Marco

P.S. @Andy :  thank you for your reporting, it should be very helpful an
Italian taginfo, we've to think about it.


Il giorno gio 9 mag 2019 alle ore 09:45 Ale_Zena_IT via Talk-it <
talk-it@openstreetmap.org> ha scritto:

> In questo periodo per lavoro stò scremando i tag del planet ed ho trovato
> veramente di tutto. Se aprite taginfo scoprite che su OSM sono presenti
> oltre 74.000 chiavi.
>
> Ieri ho scaricato l'Italia ed ho tirato giù la lista dei valori di
> highway, building, railway, amenity, natural, shop, place, leisure e anche
> layer (piuttosto che niente anche lì ci sono 20 valori differenti dal range
> -5/+5 ufficialmente riconosciuto).
>
> Spicca la chiave shop con 836 valori. Secondi i building, che tra errori
> di digitazione e creazione di tag di fantasia totalizzano 771 valori
> diversi. Al terzo posto le amenity con 632 valori diversi.
>
> Se vi volete fare un'idea di quanta spazzatura abbiamo in Italia ( e
> magari correggerne un pò dalle vostre parti) potete visualizzare questo
> foglio di calcolo
> https://drive.google.com/open?id=16iLpVhbh0jlRE80ezsFLQVANoS4gr9YD
>
>
> Alessandro Ale_Zena_IT
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Yves]

Some validation tools, like Osmose, make great efforts to maintain a 'false 
positive' database.
Also, I don't think such validation of building orthogonality should take place 
at editing stage. A hint to the squaring tool or shortcut when someone is 
mapping almost square buildings is probably a better user experience.
Yves 

Le 10 mai 2019 19:57:17 GMT+02:00, Stefan Keller  a écrit :
>Hi,
>
>Trying to get focus back on the thread topic.
>
>Storing hints like nosquare=yes (or square=no) is not best practice of
>data curation on w worldwide level.
>
>At Thu., 9. Mai 2019 23:56 Simon Poole  wrote:
>> The question was not about validating square or not square buildings,
>it
>> is about storing a hint for iDs validation mechanism permanently in
>OSMs
>> data. There is some precedent for doing so, as was mentioned in the
>github
>> issue, still it is a bit controversial and discussion when adding
>such a
>> feature should be expected.
>...
>> I believe the issue is more about the unwillingness to take community
>> feedback seriously ...
>
>This attitude needs to be changed. I expect a discussion on tags like
>this on a broader level (i.e. outside issue trackers) _before_ it's
>being implement in an editor like iD.
>
>> Which brings us back full circle to the discussion of the privileged
>position
>> of the default editor on openstreetmap.org and the related
>transparency ...
>
>Currently the OSMF Board is doing a community survey about topics and
>issues that matter to us (https://osmf.limequery.org/489698?lang=en ).
>I think this issue becomes one of my inputs.
>
>:Stefan
>
>Am Fr., 10. Mai 2019 um 15:47 Uhr schrieb Mikel Maron
>:
>>
>> > I believe the issue is more about the unwillingness to take
>community feedback seriously at all when it doesn't coincide with the
>opinions already held by the developers. Which brings us back full
>circle to the discussion of the privileged position of the default
>editor on openstreetmap.org and the related transparency (aka who is
>holding the purse strings) and the non-existent community control or
>even just control by the OSMF.
>>
>> This is a very interesting paragraph, dense with deep topics for the
>OSM project. These topics should separate this from the particulars of
>individual situations, because the dynamics are not unique to any
>single component of the OSM data and software ecosystem. OSM has always
>been a muddle and arguably one of the reasons for its success. In OSM
>people disagree, there's strong points of view and discussion,
>sometimes it resolves, often times we continue to muddle through. Yes,
>the OSMF has ultimately legal authority over all aspects of the project
>but by design and history, exercises it very selectively. And community
>is a very amorphous concept, with disagreements over what that means
>and how it functions.
>>
>> Certainly the shape of the OSM project has outgrown the systems we
>haphazardly put in place for governance and community back in 2007.
>It's worth stepping back from many of the recent heated issues in the
>community, and look at how they are the result of growth without
>intentional adaptation, and consider what kind of approach we can take
>to imagine what OSM is like in the next 15 years.
>>
>> -Mikel
>>
>> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>>
>>
>> On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole
> wrote:
>>
>>
>>
>> Am 09.05.2019 um 23:14 schrieb Mikel Maron:
>>
>> > What do you think? Should the next version of iD be deployed on
>www.openstreetmap.org?
>>
>> Absolutely. My understanding is this feature will greatly improve
>data quality in OSM. I think it's fair to validate squareness of
>existing buildings. Appreciate the great work of the iD team.
>>
>> The question was not about validating square or not square buildings,
>it is about storing a hint for iDs validation mechanism permanently in
>OSMs data. There is some precedent for doing so, as was mentioned in
>the github issue, still it is a bit controversial and discussion when
>adding such a feature should be expected.
>>
>> [Rant on the massively overrated concern for buildings in the first
>place and the background why people think that such a validation is
>necessary omitted]
>>
>> Also commend your attention to tagging issues Michael. There's
>certainly a broader issue with how tags are managed in OSM. In short
>it's a mess all around and is in need of a rethink. I don't think this
>minor issue is a "hill to die on" however.
>>
>> I believe the issue is more about the unwillingness to take community
>feedback seriously at all when it doesn't coincide with the opinions
>already held by the developers. Which brings us back full circle to the
>discussion of the privileged position of the default editor on
>openstreetmap.org and the related transparency (aka who is holding the
>purse strings) and the non-existent community control or even just
>control by the OSMF.
>>
>> Simon
>>
>>
>>
>> -Mikel
>>
>> * Mikel Maron * +14152835207 

Re: [talk-cz] Body záchrany Lesy ČR

[Marián Kyral]

10. května 2019 18:56:54 SELČ, Spratek  napsal:
>Co se týče duplicit, řešil jsem, access_point a assembly_poit o
>emergency_access_point jsem neměl páru.

No a přesně o tom je ta nutnost to nejprve prodiskutovat  Víc hlav víc ví.

Marián
-- 
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

On Fri, 10 May 2019 at 16:00, Tom Ka  wrote:

> jen pro jistotu:
>
> https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy ČR
>
> https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy%20%C4%8CR%2C%20s.p
> .
>
> https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy%20%C4%8CR%20a.s
> .
>
> za mne asi ten s.p. je nejvhodnejsi.
>

 Jo a tady se přimlouvám jen za "Lesy ČR", bez právní povahy společnosti.

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

On Fri, 10 May 2019 at 18:57, Spratek  wrote:

> Co se týče souhlasu komunity, tak se chci omluvit, ale už jsem na to neměl
> sílu ani čas.
> Získat souhlas od Lesů ČR mi trvalo skoro 2 roky .
>

Nechci znít hrubě, ale ony by ty body někam utekly? Stačilo napsat sem do
mail-listu "lidi, mám souhlas LČR (link na souhlas) s importem dat o bodech
záchrany. Data jsou tady: (link na data). Už nemám sílu a čas udělat
import. Chopí se toho někdo?" Tobě by to ušetřilo řádově hromadu času (jen
délka toho mailu by byla čtvrtinová oproti poslednímu vysvětlujícímu
poslanému sem do listu) a ostatní (třeba Majku) by to stálo času asi tak
stejně, ne-li míň.

souhlas Lesů ČR mám, pokud mi někdo řekne kam ho mam poslat, tak ho tam
> pošlu.
>

Souhlas patří na OSM wiki, AFAIK sem:
https://wiki.openstreetmap.org/wiki/Cs:WikiProjekt_%C4%8Cesko/freemap#Dokon.C4.8Den.C3.A9_importy
Pokud nevíš jak editovat wiki nebo na to nemáš čas, přepošli mail se
souhlasem buď sem do listu nebo na spo...@openstreetmap.cz, on už si s tím
někdo poradí. Díky.

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Pierre Béland via talk]

May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller  wrote 
: 
> Trying to get focus back on the thread topic.

> Storing hints like nosquare=yes (or square=no) is not best practice of
> data curation on w worldwide level.
I dont think either that this is the solution.  We have to look where these 
problems come and try to correct from the source.  Adding  such tag will not 
help software tools to identify where we have problems and can create some 
missunderstanding about its meaning. And experienced mappers are more and more 
reluctant to correct inprecise building mapping.

For Newbies, Building Quality Analysis last year this show some Tasking Manager 
projects with some 60% of unsquarred buldings (see 
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md).
 
The same problem for the DR Congo Ebola response in november where we had to 
restart mapping Butembo in an emergency response and restrict mapping to 
experienced mappers.

For an editor like iD, it can participate with other solutions like better 
training to assure that Newbies understand what Building tracing really mean 
and give then some feedback, like for example saying before save "You have 10 
over 12 buildings that are unsquarred.  If you dont know how to make 
rectangular buildings, you should ask for help before you continue.  Do you 
want to send data anyway ?"

We have the same problem with some Building import projects and I think that 
this needs to be fixed where it originates, before it goes in the database.  
For newbies, this mean more training and monitoring in particular in the 
context of Mapathons.
For Imports, this mean to analyze carefully and correct the data before the 
Import.
 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-de] Übersetzung MAPS.ME

[nmxosm]

Hallo,

vielen Dank für alle Anmerkungen. Ich habe sie jetzt umgesetzt. 

>* Ich hätte "Installateur" nicht zwingend ersetzt, stattdessen eher
>"Klempner" hinzugefügt. Kenne Leute, die das Wort "Installateur"
>durchaus eher nutzen.
Entsprechend der Erklärung von Sebastian habe ich es zurück geändert, aber 
Klempner als alternativen Suchbegriff erhalten.

>* Gibt es einen Grund, warum du z.B. "motorway.tunnel" nicht mit
>"Autobahntunnel" übersetzt hast?
Nein. Ist angepasst.

>PS.: Ich finde es gut, dass du "historic.tomb" von "Attraktion" zu
>"Grabstätte" geändert hast. Dein Vorgänger hatte wohl eine menge
>schwarzen Humor :D
Das wäre sehr traurig. Ich gehe aufgrund der Datei davon aus, dass alle 
"historic..." Objekte allgemein mit Attraktion übersetzt wurden. 


>Ich habe das Wort 'Buchmacher' noch nie gehört. Spontan hätte ich einen
Handwerksberuf vermutet.
So ging es mir auch. Wieder etwas gelernt.

Viele Grüße
Nmxosm

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] OSMF Board face-to face meeting: Suggest the topics and issues that matter to you

[Rob Nickerson]

Hi all,

My personal (non OSM UK company) response to the survey was as follows.
Given time constraints (the meeting is in May and they need time to digest
responses before then), I encourage others to submit personal responses.

---

OSM is big. It would be great if at the end of your meeting you have a
clear idea of which small part you want to help with. The OSMF states it is
"supporting [and] encouraging the growth, development and distribution of
free geospatial data". Which bits are the community perfectly capable of
doing on their own, and where is the community struggling after 15 years?

My take on it is that the community is great at collecting data (by ground
survey, promoting release of open data, etc) and have great technical
expertise. Where I feel the OSMF can add value is in community building /
cohesion. The decentralised nature of the project has led to a fragmented
community which can boil over into damaging debates based on "us versus
them" mindsets (e.g. Craft Mappers versus Corporate/Robot Mappers, Europe
vs USA, Humanitarian vs Local mapping, etc). My advise would be to focus on
building a healthy community and let us deliver the rest.

P.S. I have no idea how to achieve this (sorry) but my gut instinct is that
we need to use https://www.openstreetmap.org/ to highlight more about the
community as well as the map data.

---

Best regards,
*Rob*


On Thu, 9 May 2019 at 20:37, Rob Nickerson 
wrote:

> Hi all,
>
> Some may be interested in completing the following super short survey:
>
>
> https://blog.openstreetmap.org/2019/05/09/osmf-board-face-to-face-meeting-suggest-the-topics-and-issues-that-matter-to-you/
>
> For those who don't know, the OSMF is the "international not-for-profit
> organization supporting, but not controlling, the OpenStreetMap Project. It
> is dedicated to encouraging the growth, development and distribution of
> free geospatial data and to providing geospatial data for anyone to use and
> share."
>
> The OSMF board of directors tend to meet in person once a year and this is
> your opportunity to influence what they will cover at their May 2019
> meeting.
>
> Best regards,
> *Rob*
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] QA annotation/hinting Was: iD führt nosquare=yes für nicht rechtwinklige Gebäude ein (WAS: Besorgt über den iD-Editor)

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 10:56, Florian Lohoff  wrote:
> 
> Und ich fände es nicht schlecht
> das ganz klar in eine Hierarchie zu gliedern um deutlich zu machen
> das es hier nur um annotation/hinting für die Validatoren geht.


bei nohousenumber geht es nicht nur um qa, das kann auch Adressbestandteil sein.

Gruß, Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Modif majeure merdique

[jabali]

Je vais passer pour le vilain méchant de service mais tant pis, j'assume.

Quelqu'un qui rentre des lieux-dits sous forme office=government ;
shop=travel agency avec mapsme comme outil et ceci pour 100% de ses
contributions n'est pas un familier d'OSM ni de son fonctionnement et des
ses règles.
Les BD  bano, fantoir, cadastre lui sont vraisemblablement inconnues.
D'ailleurs, celui qui est familier de ces sources ne travaille pas avec
MapsMe

Reste "arpenter" le terrain...
Il n'y a pas d'infos sur le terrain. Certes on peut bien connaitre et
reconnaitre  son coin mais de là à rentrer environ 1200 nodes lieux-dit  en
seulement 14 jours en allant voir tous les paysans; forestiers; "gens du cru
" sur une zone aussi grande, intervenants qui, bien sûr, connaissent 100%
des lieux-dit de la carte IGN et au mêmes endroits. ( même ceux sur le
terrain d'aviation ).

Je ne crie pas "au loup" car se sont des erreurs de débutant souvent
sincères, mais le recoupage avec la carte IGN est troublant, pour ne pas
dire sans appel.
IGN
https://i.postimg.cc/G3D0kD0K/beauvais-aerodrome.jpg
A comparer avec osm.

Perso, sans infos plus convaincantes, je ferais un revert





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Body záchrany Lesy ČR

[Michal Fabík]

On 5/10/19 4:41 PM, Petr Vozdecký wrote:
2) existují i jiní operátoři, nebo se lze domnívat, že se tímto 
dostáváme na majoritu všech bodů záchrany v ČR?


Na území vojenských újezdů to jsou Vojenské lesy a statky ČR.

--
Michal Fabík


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Stefan Keller]

Hi,

Trying to get focus back on the thread topic.

Storing hints like nosquare=yes (or square=no) is not best practice of
data curation on w worldwide level.

At Thu., 9. Mai 2019 23:56 Simon Poole  wrote:
> The question was not about validating square or not square buildings, it
> is about storing a hint for iDs validation mechanism permanently in OSMs
> data. There is some precedent for doing so, as was mentioned in the github
> issue, still it is a bit controversial and discussion when adding such a
> feature should be expected.
...
> I believe the issue is more about the unwillingness to take community
> feedback seriously ...

This attitude needs to be changed. I expect a discussion on tags like
this on a broader level (i.e. outside issue trackers) _before_ it's
being implement in an editor like iD.

> Which brings us back full circle to the discussion of the privileged position
> of the default editor on openstreetmap.org and the related transparency ...

Currently the OSMF Board is doing a community survey about topics and
issues that matter to us (https://osmf.limequery.org/489698?lang=en ).
I think this issue becomes one of my inputs.

:Stefan

Am Fr., 10. Mai 2019 um 15:47 Uhr schrieb Mikel Maron :
>
> > I believe the issue is more about the unwillingness to take community 
> > feedback seriously at all when it doesn't coincide with the opinions 
> > already held by the developers. Which brings us back full circle to the 
> > discussion of the privileged position of the default editor on 
> > openstreetmap.org and the related transparency (aka who is holding the 
> > purse strings) and the non-existent community control or even just control 
> > by the OSMF.
>
> This is a very interesting paragraph, dense with deep topics for the OSM 
> project. These topics should separate this from the particulars of individual 
> situations, because the dynamics are not unique to any single component of 
> the OSM data and software ecosystem. OSM has always been a muddle and 
> arguably one of the reasons for its success. In OSM people disagree, there's 
> strong points of view and discussion, sometimes it resolves, often times we 
> continue to muddle through. Yes, the OSMF has ultimately legal authority over 
> all aspects of the project but by design and history, exercises it very 
> selectively. And community is a very amorphous concept, with disagreements 
> over what that means and how it functions.
>
> Certainly the shape of the OSM project has outgrown the systems we 
> haphazardly put in place for governance and community back in 2007. It's 
> worth stepping back from many of the recent heated issues in the community, 
> and look at how they are the result of growth without intentional adaptation, 
> and consider what kind of approach we can take to imagine what OSM is like in 
> the next 15 years.
>
> -Mikel
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
> On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole  wrote:
>
>
>
> Am 09.05.2019 um 23:14 schrieb Mikel Maron:
>
> > What do you think? Should the next version of iD be deployed on 
> > www.openstreetmap.org?
>
> Absolutely. My understanding is this feature will greatly improve data 
> quality in OSM. I think it's fair to validate squareness of existing 
> buildings. Appreciate the great work of the iD team.
>
> The question was not about validating square or not square buildings, it is 
> about storing a hint for iDs validation mechanism permanently in OSMs data. 
> There is some precedent for doing so, as was mentioned in the github issue, 
> still it is a bit controversial and discussion when adding such a feature 
> should be expected.
>
> [Rant on the massively overrated concern for buildings in the first place and 
> the background why people think that such a validation is necessary omitted]
>
> Also commend your attention to tagging issues Michael. There's certainly a 
> broader issue with how tags are managed in OSM. In short it's a mess all 
> around and is in need of a rethink. I don't think this minor issue is a "hill 
> to die on" however.
>
> I believe the issue is more about the unwillingness to take community 
> feedback seriously at all when it doesn't coincide with the opinions already 
> held by the developers. Which brings us back full circle to the discussion of 
> the privileged position of the default editor on openstreetmap.org and the 
> related transparency (aka who is holding the purse strings) and the 
> non-existent community control or even just control by the OSMF.
>
> Simon
>
>
>
> -Mikel
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
> On Thursday, May 9, 2019, 4:18:20 PM EDT, Michael Reichert 
>  wrote:
>
>
> Hi,
>
> this could be seen as a tagging discussion but I think that it is a
> discussion on governance and power. That's why this email goes to the
> Talk mailing list.
>
> Quincy Morgan, one of the maintainers of iD, invented a new tag called
> nosquare=yes today which should be added 

Re: [Talk-de] Übersetzung MAPS.ME

[Sebastian Dicke]

Hallo,


Klempner und Installateur sind nicht ein Beruf.


Klempner:
https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/suchergebnisse/kurzbeschreibung=2168=klempner



Installateur aka Anlagenmechaniker für Sanitär-, Heizungs- und
Klimatechnik:
https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung=15164=Anlagenmechaniker%2Fin+-+Sanit%C3%A4r-%2C+Heizungs-+und+Klimatechnik



Wobei es auch noch andere Typen von Installateuren gibt, aber das ist
der Typ von Installateur, der sich im Wiki zu craft=plumber findet. Auf
der deutschen Seite findet sich auch diese Berufsbezeichnung.


Grüße


Sebastian


On 10.05.19 11:36, Hauke Stieler wrote:
* Ich hätte "Installateur" nicht zwingend ersetzt, stattdessen eher
"Klempner" hinzugefügt. Kenne Leute, die das Wort "Installateur"
durchaus eher nutzen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] Pilone

[Ivo Reano]

historic=wayside_shrine
+
name=Pilone Gardetta


È un caso piuttosto ambiguo se non è presente una nicchia! Di solito casi
di questo genere sono semplicemente dei cumuli di pietre fatto per liberare
il terreno ma la pietra sul "tetto" mi fa cambiare idea...

Solitamente si trova sul colmo della casa, e serve per evitare che le
masche si fermino a sedersi, gettando il malocchio.
In questo caso lo distingue da un "bunom" ovvero una cumulo di pietre usato
come sorta di segnale di confine, o anche segnale ben visibile da lontano
che serve come punto di riferimento nelle zone di alpeggio, o per ritrovare
la strada con la nebbia o per segnalare il confine di un pascolo.

Per cui sono propenso a considerare la pietra sulla sommità con un senso
"quasi" religioso. Di devozione.
Andrebbero aggiunti anche
religion=christian
e la confessione...
Per religion sono abbastanza convinto, ma la mancanza di altri segni rende
difficile assegnare la confessione.

Il giorno ven 10 mag 2019 alle ore 19:01 solitone  ha
scritto:

> A fianco di un un sentiero in montagna ho incontrato questo:
>
>
>  Si chiama Pilone Gardetta. E’ una specie di ometto di pietre evoluto,
> l’anello di congiunzione tra gli ometti e piloni e le edicole votive. In
> montagna ce ne sono diversi.
>
> Come mapparlo? Con il classico historic=wayside_shrine?
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Pilone

[solitone]

A fianco di un un sentiero in montagna ho incontrato questo:



 Si chiama Pilone Gardetta. E’ una specie di ometto di pietre evoluto, l’anello 
di congiunzione tra gli ometti e piloni e le edicole votive. In montagna ce ne 
sono diversi.

Come mapparlo? Con il classico historic=wayside_shrine? 




___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] Body záchrany Lesy ČR

[Spratek]

Zdravím, 
souhlas Lesů ČR mám, pokud mi někdo řekne kam ho mam poslat, tak ho tam pošlu.

Co se týče souhlasu komunity, tak se chci omluvit, ale už jsem na to neměl sílu 
ani čas.
Získat souhlas od Lesů ČR mi trvalo skoro 2 roky . 
Dnes to funguje tak, že Lesy ČR dají souhlas, ale datově body spravuje HZS.
Takže tam vzniká nějaký komunikační šum a HZS v tom mají trochu bordel, některé 
body měli nesmyslné souřadnice.
Nakonec se to všechno nějak podařilo doladit, ale času jsem na tom strávil víc 
než jsem chtěl.

Co se týče duplicit, řešil jsem, access_point a assembly_poit o 
emergency_access_point jsem neměl páru.
Tzn. bod, který byl vyhodnocen jako duplicitní, tak jsem smazal a přehrál 
aktuální verzí (je možné, že nějaké body mi utekly).

Současný stav bodů by měl být ze strany LČR konečný a odsouhlasený HZS, tzn 
podle mých informací další body už přidělávat nebudou.

Co se týče klíče name tak "Bod záchrany - Rescue Point" je oficiální název bodů 
tzn. podle mě je to "Obvyklý základní název" viz 
https://www.hzscr.cz/clanek/body-zachrany-na-uzemi-cr.aspx

Co se týče klíče source postupoval jsem podle 
https://wiki.openstreetmap.org/wiki/DE:Tag:emergency%3Daccess_point možná by 
bylo dobré to tam doplnit.

Jinak co vím, tak body záchrany zřizují národní parky, některé obce a různé 
státní molochy a prý i někteří soukromí majitelé lesů, ale to bude v řádů 
jednotek. Dával jsem dotaz HZS, jestli nemají seznam vlastníků bodů, ale zatím 
odpověď nedošla.

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] TfL Cycling Infrastructure Database

[Martin Lucas-Smith - CycleStreets]

On Fri, 10 May 2019, Jez Nicholson wrote:


Their data is highly accurate,


Yes, that seems to me as well to be the case. We're just awaiting more 
images to be uploaded to the site (every feature has two images, but not 
all are GDPR-cleared yet).


I'd welcome as many eyes as possible on the sample data to get a good 
assessment of the data quality.

https://tflcid.cyclestreets.net/


and there's definitely going to need to be some clever conflation 
tooling. Bike stands are fine, but advance stop lines, etc. are 
specialist subjects in my book. I'm sightly overawed by the quantity and 
am unsure whether volunteers are going to be able to get through it, but 
again that is something you'll be talking about in your report, no?


Yes, that will be a key issue. Bear in mind that the sample data is only 
one of *25* areas, so there's a lot of data.


Clearly, pre-translations in the data to convert the CID schema to OSM 
tagging would remove a lot of manual work, and a conflation tool could work 
on a similar basis to the England Cycling Data project tool [1]. I think 
there's scope for some pre-processing (e.g. eliminating locations in the 
CID data that clearly already exist in OSM based on a nearness search), and 
the ability for multiple features to be done at once, e.g. a screen where 
say 10-20 cycle parking locations could be reviewed at once. Again, views 
on this would be extremely welcome.



There would need to be some tool development regardless of who does the 
conflation.


Indeed. I'd welcome pointers to up-to-date information on the state of such 
tools at the moment, e.g. the JOSM tool, and other developments currently 
happening.



[1] See images on: 
https://wiki.openstreetmap.org/wiki/England_Cycling_Data_project




Martin, **  CycleStreets - For Cyclists, By Cyclists
Developer, CycleStreets **  https://www.cyclestreets.net/


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] TfL Cycling Infrastructure Database

[Jez Nicholson]

Firstly, exceptionally pleased that TfL see OSM as *the* major people
access cycling data :D

Their data is highly accurate, and there's definitely going to need to be
some clever conflation tooling. Bike stands are fine, but advance stop
lines, etc. are specialist subjects in my book. I'm sightly overawed by the
quantity and am unsure whether volunteers are going to be able to get
through it, but again that is something you'll be talking about in your
report, no? There would need to be some tool development regardless of who
does the conflation.

Also, you could start some discussion in the talk tab of that wiki page if
there's anything that needs thrashing out.

...and now I know what a "Sheffield" bike stand is :)

Regards,
  Jez

On Fri, May 10, 2019 at 3:42 PM Martin Lucas-Smith - CycleStreets <
list-osm-talk...@cyclestreets.net> wrote:

>
>
> Transport for London (TfL) have created a new database of cycling
> infrastructure, containing 240,000 assets, covering all of Greater London.
>
> This groundbreaking database contains every cycle infrastructure asset
> within Greater London, including assets on and off-carriageway. The assets
> surveyed are: cycle parking; signals; signage; traffic calming measures;
> restricted points (e.g. steps); advanced stop lines; crossings; cycle
> lanes/tracks; and restricted routes (e.g. pedestrian only routes).
>
> TfL is keen to make this available to the OpenStreetMap community under a
> compatible open license, to ensure maximum use of the CID. TfL is also
> potentially willing to consider tool development to help facilitate
> sensitive merging in of this data.
>
> There is a new Wiki page, giving full details, at:
> https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database
>
>
> Demonstrator map:
> -
>
> A demonstrator map, for the purposes only of evaluation by the OSM
> community at this stage, has been created by CycleStreets.
>
> This demonstrator map contains only one of the 25 areas that have been
> surveyed.
>
> We are specifically seeking comments on data quality and usefulness of
> this
> data from the OSM community. Initial analysis by CycleStreets is that the
> data is of excellent quality, and very suitable for conflation into OSM,
> to
> increase both comprehensiveness and metadata quality.
>
> https://tflcid.cyclestreets.net/
> (Use the controls on the right to change feature type.)
>
> Usage notes: The controls on the right of the map allow the different
> feature types to be selected. The OSM layer (available at zoom level 19+)
> also provides a live feed from the OSM API, to enable quick comparisons.
> The two photos of each asset are in the process of being supplied; those
> already available and cleared in GDPR terms are included in the popup.
>
> It is stressed that at this point, no permission is given for re-use of
> the
> data in any way, but TfL strongly intends to make this available in
> future.
> All 25 areas would be covered in the final data release, not merely the
> one
> shown currently in the demonstrator map.
>
>
> Feedback is very strongly encouraged, as soon as possible. What are
> people's thoughts?
>
>
> Martin, **  CycleStreets - For Cyclists, By Cyclists
> Developer, CycleStreets **  https://www.cyclestreets.net/
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] Body záchrany Lesy ČR

[Majka]

Ty body záchrany mám zatím v osm souboru, je to připravené na slučování.
To sloučení nebude velký problém, pokud se domluvíme jak přesně. Nijak na to 
nechvátám, stejně ještě dlužím aktualizace schránek. 

Ten souhlas jsem zmiňovala i u komentáře na tom původním changesetu, když jsem 
hlásila revert. Bez toho souhlasu se do ničeho pouštět nebudu. Stejně ještě 
tady znovu nahlásím, jak přesně to budu chtít nahrát, než k tomu případně 
dojde. ___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

pá 10. 5. 2019 v 16:58 odesílatel Jan Macura  napsal:
>> Hlasuji pro smazani name. Takze by melo zustat:
>>
>> emergency=access_point
>> emergency_telephone_code=112
>> operator=Lesy ČR, s.p.
>> ref=RA028
>
> A co duplicitní značení emergency=access_point vs. 
> highway=emergency_access_point?  To nezohledníme?

jen opet doplnim:

https://taginfo.openstreetmap.cz/tags/emergency=access_point
https://taginfo.openstreetmap.cz/tags/highway=emergency_access_point

Kdyz koukam na wiki, asi bych skoro dal ted oboji a pokud se schvali
emergency=acces_point, tak pak highway zrusil. Tam se mi uz z principu
nelibi, ze highway= je pouze pro bod, to je dost proti sobe.

Bye

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

On Fri, 10 May 2019 at 17:13, Majka  wrote:

> Bez toho souhlasu se do ničeho pouštět nebudu. Stejně ještě tady znovu
> nahlásím, jak přesně to budu chtít nahrát, než k tomu případně dojde.
>

+1

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Borne Michelin

[Gwenaël Jouvin via Talk-fr]

Pour entrer dans la technique, chaque panneau ou borne fabriqués par Michelin 
est constitué de 2 éléments :
— la partie « signal » est en lave émaillée, sous la forme d’une ou plusieurs 
dalles ;
— le corps est en béton armé, le signal est surmoulé dedans ;
— après séchage, le corps est peint en blanc sur la face utile, en gris foncé 
sur la face masquée.

Selon le type de panneau, les dalles ont chacune une référence ou une date qui 
sont inscrites à l’émaillage (à main levée, pas au pochoir), avant cuisson : ça 
donne, en gros, la date de la cuisson (du moins, d’une des cuissons) au jour 
près.
Pour moi, difficile de remettre ça en cause puisqu’il y a une contrainte 
technique : l’émail est appliqué sous forme liquide.

Le corps en béton est daté à l’année près et, selon l’état du béton, bien 
souvent illisible. Ça donne la date du moulage.
De la même manière, le béton se travaille à l’échelle de l’heure, donc peu de 
doute possible.

La mise en service est indéterminable puisque ça correspond à la date de pose 
du panneau. On peut se douter que c’est dans la ou les années qui suivent sa 
fabrication, mais va savoir…


La signalisation Michelin n’a de « pierre » que le support en lave qui est 
totalement invisible sur un panneau en bon état car il est émaillé sur la face 
utile.
Sur les panneaux abîmés, on voit que la dalle fait environ 2 cm d’épaisseur.

Les bornes kilométriques en béton peint ou en pierre massive ne sont pas des 
Michelin qui, elles, on 3 faces émaillées.


Michelin était fabricant au même titre que l’était Neuhaus et d’autres sociétés 
vendeuses de signaux.
Les opérateurs étaient les gestionnaires des routes le long desquels les 
signaux étaient installés.


Gwenaël


Le 10/05/2019 à 11:08, marc marc a écrit :
> Le  8 mai 2019, Gwenaël Jouvin via Talk-fr a écrit :
>> date de fabrication et date de mise en service sont différentes
>> Dans ce genre de cas, la date de mise en service est inconnue.
> 
> ce qui me faisait réagir c'est "fabriquer une pierre" (= la formation 
> géologique), enfin bref c'est du détail.
> Mais il y a une source qui dit que la date connue n'est pas celle
> de mise en service ? j'ai du mal à croire que quelqu'un a taillé/peint
> une borne, l'ai gardé des années dans un coin pour ne l'utiliser
> que + tard. c'est en cela que je réagissais aux différents _date :
> ne pas en arriver à ce que l'un dise que c'est pas la date de mise
> en service mais celle de fabrication, un autre dira que c'est la date
> de la commande, un autre dira que c'est la date de l'inauguration...
> alors que travailler sur des éléments aussi vieux a une précision
> très relative, hormis les cas où c'est écrit sur l'élément
> (c'est ce que tu avais évoqué pour les abribus)
> 
> Le 10.05.19 à 10:42, Rpnpif a écrit :
>> Par contre, name=Ancienne borne Michelin ne convient pas 
>> car c'est plutôt une description que le nom.
> 
> ce n'est en effet pas un nom.
> mais cela mériterait sans doute d'être structuré dans un tag.
> Michelin était-il le fabriquant et/ou l'opérateur ?
> qlq chose genre manufacter=Michelin ou was:operator=Michelin
> permettrait aux passionnés de les retrouver.
> voir de leur proposer d'intégrer leur bdd dans osm
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

On Fri, 10 May 2019 at 15:42, Majka  wrote:

> No, já osobně bych to vymazala. Ten hlavní tag totiž neříká nic jiného...
>

No právě. A note slouží jako poznámka editorům OSM, takže těm to novou
informaci určitě nedá. V description by to mohlo dát novou informaci
uživatelům těch vykreslovačů, které jinak ukážou jen tečku s kódem "TC002"
nebo tak něco.

On Fri, 10 May 2019 at 16:00, Tom Ka  wrote:

> Hlasuji pro smazani name. Takze by melo zustat:
>
> emergency=access_point
> emergency_telephone_code=112
> operator=Lesy ČR, s.p.
> ref=RA028


A co duplicitní značení emergency=access_point vs.
highway=emergency_access_point?  To nezohledníme?

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL

[Marek]

Is there a possibility to have these files converted to CVG? Also, the 
resolution required is bigger than the files you have sent.

Marek Polák


Ahoj, asi to ma byt SVG a jednoduse konvertovat to nejde, jedno jsou
vektory a jedno bitmapa.

Bye

pá 10. 5. 2019 v 16:33 odesílatel Marek  napsal:


Potřeboval bych poradit, podpora mi napsala že potřebuje ikonky ve formátu 
CVG, ale já je mám staženy v BMP a nemůžu přijít na to jak je konvertovat 
na požadovaný formát.

Marek Polák

Rekace od vyvojaru:

Our developers are currently working on a way to more efficiently handle 
gas stations which also have kiosks. The correct behavior should be to 
display the gas station brand icon even if there is the kiosk as well.


For this development, we have created case C2227 and we are looking into 
ways to fix it and improve the behavior. I will let you know as soon as I 
have more info. Safe travels!


mahdi

Vit Semenec via talk-cz wrote on 05/05/2019 01:34 PM:

Ahoj,
nejprve děkuji za odpovědi, přečetl jsem si je hned, ale jak na webu na ně 
odpovědět, je mimo mé schopnosti a do mailu mě to jako v té době 
neregistrovanému  nepřišlo (neměl jsem jak na vlákno odpovědět, jen bych 
nejspíš založil další).


Ještě další příklady:
Ikona benzínky Shell se v Magic Earth nezobrazuje ještě např. zde.   A 
tam je co zadané špatně???

https://www.openstreetmap.org/edit#map=19/50.69258/14.54223
https://www.openstreetmap.org/edit?way=172860536#map=19/50.03445/14.53629

A zde je to OK:
https://www.openstreetmap.org/edit?way=356914203#map=20/50.04682/14.55231
https://www.openstreetmap.org/edit#map=19/49.98401/14.60295

Nemusí být benzinka označená hlavně jako BOD a ne jen jako PLOCHA?


U benzínek, jak právě koukám se na označení plochy budovy náhodně používá 
Čerpací stanice/Obchodní budova/Průmyslová budova/Budova/Budova občanské 
vybavenosti. Ale u většiny je i označena jako bod.


Tady je dokonce jako plocha Benziny vyznačena nejen budova, ale úplně celá 
i zatravněná oblast s parkovištěm:

https://www.openstreetmap.org/edit#map=19/50.22100/15.80720


Moc možností, každý přispěvovatel to pochopí jinak a pak se s daty mají 
aplikace nějak poprat :(


---
Po přečtení příspěvku rekonstrukce multipolygonů, jsem se krapet vyděsil. 
Je toho tolik, co začínající přispěvovatel vůbec netuší a jak snadno 
nevědomky znehodnodnotí práci někoho jiného. Chybí zde funkce nějakého 
zámku, na věci importované z přesného zdroje, nebo takto precizně finálně 
zadané.

---

V.

Dne 05.05.2019 v 10:18 mahdi1234 napsal(a):

cau,

trochu sem se na to dival, a vypada, ze pokud je vyplnen jen "brand", tak 
se ikona nezobrazi, pokud "name" tak jo (zatim to nebudu v osm doplnovat, 
at to muzou spravit v ME).


https://www.openstreetmap.org/way/50734705 - na mape bez ikony
https://www.openstreetmap.org/way/320770862 - na mape s ikonou

zaroven pokud ma tag kiosk, tak se zobrazi na mape nakupni kosik, opet si 
myslim, ze je logictejsi logo site


https://www.openstreetmap.org/node/877762987

Taky pak spolecne s Markem posilame navrh na doplneni ikon prozatim pro 
Benzina, Eurooil, Globus a Makro, klidne dejte navrh pro nakou dalsi vetsi 
sit v CR, co se v ME nezobrazi, poslu to asi ve stredu na svatek.


mahdi

Marek wrote on 05/02/2019 12:14 PM:

Hello Marek,


Thank you for contacting us.


The Magic Earth app has a database with gas station icons which are then 
automatically displayed on the map. You do not need to set up something 
specific in the settings for that.



Can you please give us examples of what gas station icons are not displayed 
and in which locations? Screenshots would be ideal to have.



Also, if you have any other questions or suggestions, we are here to help. 
Safe travels!



Best regards,

Razvan

Marek Polák

Jak pise Marek, mapy cca 2 mesice, ted to chvilu trva kvuli nove bete 
probihaji posledni 3 tydny (bugiku bylo povicero). Po vikendu by mohla byt 
nova verze, takze dalsi update map bude chvili trvat.


Podpora bezne reaguje do dvou pracovnich dnu - supp...@generalmagic.com

mahdi

marek wrote on 04/27/2019 08:07 PM:

Aktualizace ma probíhá cca jednou za 2 měsíce.

Podporu mají, tak jím zkusím napsat.



Marek Polák



__
> Od: "Marián Kyral" 
> Komu: talk-cz@openstreetmap.org
> Datum: 27.04.2019 19:21
> Předmět: Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL
>

On 27. 04. 19 11:47, Vit Semenec via talk-cz wrote:
> Ahoj,
>
> popisuji jak umím :)
>
> V navigaci Magic Earth se mě u některých benzínek zobrazuje ikonka
> konkrétní značky u jiných ne.
>
> Je to tím, že Shell, OMV a MOL mají v iD editoru vlastní skupinu (asi
> dle brand:wikidata ?).

Možné to je. Dá se to odhadnout tak, že najdeš jednu benzínku, která
ikonu má a druhou, která ji nemám. Pak se porovnají tagy a chybějící se
dodají. Pak se jen počká, jestli se ta benzínka zobrazí i s ikonou. To
bude ale nějakou dobu trvat. Nevím jak často dělají aktualizaci mapových

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

Jen jeste jedna vec - je nekde ten souhlas Lesu CR s temi daty? Bez
toho je to cele u ledu.

Bye

pá 10. 5. 2019 v 16:07 odesílatel Jan Macura  napsal:
>
> P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych tomu aspoň 
> víkend na vyjádření dalších lidí z komunity.
>
> H.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

pá 10. 5. 2019 v 16:41 odesílatel Petr Vozdecký  napsal:
> 2) existují i jiní operátoři, nebo se lze domnívat, že se tímto dostáváme na 
> majoritu všech bodů záchrany v ČR?

existuji, ale Lesy CR je podle meho odhadu vyrazne nadpolovicni
vetsina. Kolem Brna jsou ale i Lesy MB nebo Mendlovka apod.

Bye

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Martinec]

Ahoj,

Ad 1: asi žádný, ale "počkáme na renderer" je cesta k limitnímu plus
nekonečnu. Konečně, nezačnou mapy.cz renderovat dálniční tlf taky po dlouhé
době existence?

Ad 2: Minimálně nějaký provozují Lesy HM Prahy spolu s hasiči...

Zdar,
HPM

Dne pá 10. 5. 2019 16:42 uživatel Petr Vozdecký  napsal:

> Jen ze zvědavosti:
> 1) které z častých renderů jsou toto schopny dnes už zobrazit?
> 2) existují i jiní operátoři, nebo se lze domnívat, že se tímto dostáváme
> na majoritu všech bodů záchrany v ČR?
>
> vop
>
> -- Původní e-mail --
> Od: xkomc...@centrum.cz 
> Komu: talk-cz@openstreetmap.org
> Datum: 10. 5. 2019 16:37:54
> Předmět: Re: [talk-cz] Body záchrany Lesy ČR
>
> Za mne klidně hned, přes víkend na to bude mít Majka alespoň čas.
>
> Jinak, řešíš i duplicity s highway=emergency_access_point? (asi jo, jenom
> pro jistotu připomínám, jelikož tak jsem body záchrany vždy značil já)
> On 10. 05. 19 16:06, Jan Macura wrote:
>
> P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych tomu aspoň
> víkend na vyjádření dalších lidí z komunity.
>
> H.
>
> ___
> talk-cz mailing 
> listtalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL

[Tom Ka]

Ahoj, asi to ma byt SVG a jednoduse konvertovat to nejde, jedno jsou
vektory a jedno bitmapa.

Bye

pá 10. 5. 2019 v 16:33 odesílatel Marek  napsal:
>
> Potřeboval bych poradit, podpora mi napsala že potřebuje ikonky ve formátu 
> CVG, ale já je mám staženy v BMP a nemůžu přijít na to jak je konvertovat na 
> požadovaný formát.
> Marek Polák
>
> Rekace od vyvojaru:
>
> Our developers are currently working on a way to more efficiently handle gas 
> stations which also have kiosks. The correct behavior should be to display 
> the gas station brand icon even if there is the kiosk as well.
>
> For this development, we have created case C2227 and we are looking into ways 
> to fix it and improve the behavior. I will let you know as soon as I have 
> more info. Safe travels!
>
> mahdi
>
> Vit Semenec via talk-cz wrote on 05/05/2019 01:34 PM:
>
> Ahoj,
> nejprve děkuji za odpovědi, přečetl jsem si je hned, ale jak na webu na ně 
> odpovědět, je mimo mé schopnosti a do mailu mě to jako v té době 
> neregistrovanému  nepřišlo (neměl jsem jak na vlákno odpovědět, jen bych 
> nejspíš založil další).
>
> Ještě další příklady:
> Ikona benzínky Shell se v Magic Earth nezobrazuje ještě např. zde.   A 
> tam je co zadané špatně???
> https://www.openstreetmap.org/edit#map=19/50.69258/14.54223
> https://www.openstreetmap.org/edit?way=172860536#map=19/50.03445/14.53629
>
> A zde je to OK:
> https://www.openstreetmap.org/edit?way=356914203#map=20/50.04682/14.55231
> https://www.openstreetmap.org/edit#map=19/49.98401/14.60295
>
> Nemusí být benzinka označená hlavně jako BOD a ne jen jako PLOCHA?
>
>
> U benzínek, jak právě koukám se na označení plochy budovy náhodně používá 
> Čerpací stanice/Obchodní budova/Průmyslová budova/Budova/Budova občanské 
> vybavenosti. Ale u většiny je i označena jako bod.
>
> Tady je dokonce jako plocha Benziny vyznačena nejen budova, ale úplně celá i 
> zatravněná oblast s parkovištěm:
> https://www.openstreetmap.org/edit#map=19/50.22100/15.80720
>
>
> Moc možností, každý přispěvovatel to pochopí jinak a pak se s daty mají 
> aplikace nějak poprat :(
>
> ---
> Po přečtení příspěvku rekonstrukce multipolygonů, jsem se krapet vyděsil. Je 
> toho tolik, co začínající přispěvovatel vůbec netuší a jak snadno nevědomky 
> znehodnodnotí práci někoho jiného. Chybí zde funkce nějakého zámku, na věci 
> importované z přesného zdroje, nebo takto precizně finálně zadané.
> ---
>
> V.
>
> Dne 05.05.2019 v 10:18 mahdi1234 napsal(a):
>
> cau,
>
> trochu sem se na to dival, a vypada, ze pokud je vyplnen jen "brand", tak se 
> ikona nezobrazi, pokud "name" tak jo (zatim to nebudu v osm doplnovat, at to 
> muzou spravit v ME).
>
> https://www.openstreetmap.org/way/50734705 - na mape bez ikony
> https://www.openstreetmap.org/way/320770862 - na mape s ikonou
>
> zaroven pokud ma tag kiosk, tak se zobrazi na mape nakupni kosik, opet si 
> myslim, ze je logictejsi logo site
>
> https://www.openstreetmap.org/node/877762987
>
> Taky pak spolecne s Markem posilame navrh na doplneni ikon prozatim pro 
> Benzina, Eurooil, Globus a Makro, klidne dejte navrh pro nakou dalsi vetsi 
> sit v CR, co se v ME nezobrazi, poslu to asi ve stredu na svatek.
>
> mahdi
>
> Marek wrote on 05/02/2019 12:14 PM:
>
> Hello Marek,
>
>
> Thank you for contacting us.
>
>
> The Magic Earth app has a database with gas station icons which are then 
> automatically displayed on the map. You do not need to set up something 
> specific in the settings for that.
>
>
> Can you please give us examples of what gas station icons are not displayed 
> and in which locations? Screenshots would be ideal to have.
>
>
> Also, if you have any other questions or suggestions, we are here to help. 
> Safe travels!
>
>
> Best regards,
>
> Razvan
>
> Marek Polák
>
> Jak pise Marek, mapy cca 2 mesice, ted to chvilu trva kvuli nove bete 
> probihaji posledni 3 tydny (bugiku bylo povicero). Po vikendu by mohla byt 
> nova verze, takze dalsi update map bude chvili trvat.
>
> Podpora bezne reaguje do dvou pracovnich dnu - supp...@generalmagic.com
>
> mahdi
>
> marek wrote on 04/27/2019 08:07 PM:
>
> Aktualizace ma probíhá cca jednou za 2 měsíce.
>
> Podporu mají, tak jím zkusím napsat.
>
>
>
> Marek Polák
>
>
>
> __
> > Od: "Marián Kyral" 
> > Komu: talk-cz@openstreetmap.org
> > Datum: 27.04.2019 19:21
> > Předmět: Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL
> >
>
> On 27. 04. 19 11:47, Vit Semenec via talk-cz wrote:
> > Ahoj,
> >
> > popisuji jak umím :)
> >
> > V navigaci Magic Earth se mě u některých benzínek zobrazuje ikonka
> > konkrétní značky u jiných ne.
> >
> > Je to tím, že Shell, OMV a MOL mají v iD editoru vlastní skupinu (asi
> > dle brand:wikidata ?).
>
> Možné to je. Dá se to odhadnout tak, že najdeš jednu benzínku, která
> ikonu má a druhou, která ji nemám. Pak se porovnají tagy a chybějící se
> dodají. Pak se jen počká, jestli se ta benzínka zobrazí i s 

Re: [talk-cz] Body záchrany Lesy ČR

[mahdi1234]

>> které z častých renderů jsou toto schopny dnes už zobrazit

Osmand umi zobrazit/vyhledat.

mahdi

Petr Vozdecký wrote on 05/10/2019 04:41 PM:
> Jen ze zvědavosti:
> 1) které z častých renderů jsou toto schopny dnes už zobrazit?
> 2) existují i jiní operátoři, nebo se lze domnívat, že se tímto
> dostáváme na majoritu všech bodů záchrany v ČR?
>
> vop
>
> -- Původní e-mail --
> Od: xkomc...@centrum.cz 
> Komu: talk-cz@openstreetmap.org
> Datum: 10. 5. 2019 16:37:54
> Předmět: Re: [talk-cz] Body záchrany Lesy ČR
>
>
> Za mne klidně hned, přes víkend na to bude mít Majka alespoň čas.
>
> Jinak, řešíš i duplicity s highway=emergency_access_point? (asi
> jo, jenom pro jistotu připomínám, jelikož tak jsem body záchrany
> vždy značil já)
>
> On 10. 05. 19 16:06, Jan Macura wrote:
>
> P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych
> tomu aspoň víkend na vyjádření dalších lidí z komunity.
>
> H.
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] STRUTTURE DI ARRAMPICATA

[Lorenzo Beltrami]

Il giorno ven 10 mag 2019 alle ore 15:52 Geometra Alberto VARALLI <
geom.vara...@gmail.com> ha scritto:

> Perfetto, l'unico problema è che così facendo la falesia non viene
> visualizzata sulla mappa se non dopo l'interrogazione.
> Ho visto che in alcuni casi viene inserito anche il tag "viewpoint" per
> visualizzare un asterisco che individua il punto.
>
> Può essere corretto?
>

Ciao Alberto,
è corretto se lì c'è anche un viewpoint, altrimenti no.

Il discorso è che la mappa su osm.org è solo esemplificativa, non mostra
tutti i tag esistenti.
I tag relativi all'arrampicata per esempio non vengono mostrati.

Ho provato a guardare anche altre mappe e per esempio ho notato che OsmAnd
(applicazione per Android) mostra correttamente i punti con col tag
climbing:sport =yes mettendo l'iconcina di uno scalatore.
Trovi alcune mappe specifiche per l'outdoor qua:
https://wiki.openstreetmap.org/wiki/Compare_Hiking_Maps

Ciao
Lorenzo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Grigory Rechistov via Talk-se]

Hej!

Här är vad som händer med importens förlopp och verktyg.

1. Jag har skapat en insticksmodul SnapNewNodes [1] som möjliggör att förena 
två 
   sträckors närliggande gränser. Modulen liknar i syftet ContourMerge men 
   kräver mindre musrörelser och musklick. Jag testade dess JAR-fil på två 
datorer
   med Linux och Windows och den brukar inte krascha. Men den är visst inte 
   buggfri just nu, så var försiktig om ni använder den, kontrollera visuellt 
att
   den inte förstör polygoner och spara ofta ditt arbete. Rapportera alla 
problem
   till mig. Jag vill förbättra insticksmodulen och fixa kända buggar men just 
   nu tror jag att insticksmodulen redan kan vara till nytta vid importen.
   
2. Jag hoppas att jag har hittat en bra kombination på filter så att varken 
viktiga
   detaljer tappas eller överflödigt många nya noder kvarstår i importdatat.
   Vingåkers kommuns importlagret tappade ganska mycket fina detaljer. Däremot 
   fick vissa kvadrater i Katrineholms kommun för mycket onödiga fina detaljer.
   I framtiden minskar antalet noder på nya kvadrater med 30-50% utan att sluta
   överensstämma med flygplansbilder. Det går alltid att göra ännu "mjukare" 
förenkling om man
   på nytt börjar se att för mycket detaljer tappas bort.
   
3. På importplanen i section "Conflation" [2] illustrerade jag alla slags
   kosmetiska problem som jag nu observerar på oredigerade import-OSM-filer samt
   de åtgärder mot dem som planeras eller är tillgängliga. Om man hittar andra 
   nya typer problem ska de läggas till dit i importplanen.

Ett av kvarstående problem som jag håller på att lösa är tillfällen när nya ytor
överlappar med befintliga vägar. I princip bör en bilväg antingen ligga helt på 
någon markanvändnings yta eller ligga helt utanför markanvändningen. 
Jag håller på att skapa ett skript/verktyg för att "ploga" bort noder och 
sträckors 
segment som ligger för nära till eller överlappar med vägar. Detta ska hjälpa 
till
att se till att importlager blir i bättre skick. 

Som förut är mitt syfte att alla som vill bidra med dataimporten kunde undvika
så mycket tråkigt arbete som möjligt genom att använda passande verktyg.
Nya markanvändningspolygoner bör inte kollidera med det befintliga datat, 
inte se helt fult ut och motsvara till verkligheten. Jag fortsätter testa dem 
på Katrineholms kommun rutor och hoppas att redigeringsprocessen blir stabil nog
för att upprepa den på andra kommuner.

Tack och ha trevlig helg!

Källor
1. https://github.com/grigory-rechistov/snapnewnodes
2. 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan#Conflation



>Пятница,  3 мая 2019, 23:58 +03:00 от egil :
>
>Hej på er
>Här finns en annan intressant importstrategi med tasking
>  manager-filer som output. 
> https://www.openstreetmap.org/user/itsamap!/diary/152909
>Kanske är detta bästa vägen även för denna import?
>(det möjliggör att ha denna data som underlag under lång tid
>framöver för folk som vill kartlägga landuse genom att utgå från NMD
>som grund om dem tycker det är lättare.)
>
>Se "merge workflow" som beskrivs här: 
>https://wiki.openstreetmap.org/wiki/Import/Catalogue/US/BingBuildings#Data_Merge_Workflow
>
>Mvh
>
>On 2019-05-01 00:36, Grigory Rechistov
>  via Talk-se wrote:
>>Hej! Kolla imports-listan där jag beskriver min nuvarande approach
>>  med masker:  
>> https://lists.openstreetmap.org/pipermail/imports/2019-April/005990.html  
>>Återkommer till talk-se-listan med fler filer, detaljer för de som
>>  vill pröva med nya vektor efter helgen. Trevlig helg!
>>
>>
>>Med vänliga hälsningar,
>>Grigory Rechistov
>>With best regards,
>>Grigory Rechistov
>>
>>
>>___
>>Talk-se mailing list
>>Talk-se@openstreetmap.org
>>https://lists.openstreetmap.org/listinfo/talk-se
>>
>___
>Talk-se mailing list
>Talk-se@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-se


С наилучшими пожеланиями,
Григорий Речистов.
Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-GB] TfL Cycling Infrastructure Database

[Martin Lucas-Smith - CycleStreets]

Transport for London (TfL) have created a new database of cycling 
infrastructure, containing 240,000 assets, covering all of Greater London.


This groundbreaking database contains every cycle infrastructure asset 
within Greater London, including assets on and off-carriageway. The assets 
surveyed are: cycle parking; signals; signage; traffic calming measures; 
restricted points (e.g. steps); advanced stop lines; crossings; cycle 
lanes/tracks; and restricted routes (e.g. pedestrian only routes).


TfL is keen to make this available to the OpenStreetMap community under a 
compatible open license, to ensure maximum use of the CID. TfL is also 
potentially willing to consider tool development to help facilitate 
sensitive merging in of this data.


There is a new Wiki page, giving full details, at:
https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database


Demonstrator map:
-

A demonstrator map, for the purposes only of evaluation by the OSM 
community at this stage, has been created by CycleStreets.


This demonstrator map contains only one of the 25 areas that have been 
surveyed.


We are specifically seeking comments on data quality and usefulness of this 
data from the OSM community. Initial analysis by CycleStreets is that the 
data is of excellent quality, and very suitable for conflation into OSM, to 
increase both comprehensiveness and metadata quality.


https://tflcid.cyclestreets.net/
(Use the controls on the right to change feature type.)

Usage notes: The controls on the right of the map allow the different 
feature types to be selected. The OSM layer (available at zoom level 19+) 
also provides a live feed from the OSM API, to enable quick comparisons. 
The two photos of each asset are in the process of being supplied; those 
already available and cleared in GDPR terms are included in the popup.


It is stressed that at this point, no permission is given for re-use of the 
data in any way, but TfL strongly intends to make this available in future. 
All 25 areas would be covered in the final data release, not merely the one 
shown currently in the demonstrator map.



Feedback is very strongly encouraged, as soon as possible. What are 
people's thoughts?



Martin, **  CycleStreets - For Cyclists, By Cyclists
Developer, CycleStreets **  https://www.cyclestreets.net/


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] Body záchrany Lesy ČR

[Petr Vozdecký]

Jen ze zvědavosti:

1) které z častých renderů jsou toto schopny dnes už zobrazit?

2) existují i jiní operátoři, nebo se lze domnívat, že se tímto dostáváme na
majoritu všech bodů záchrany v ČR?




vop



-- Původní e-mail --
Od: xkomc...@centrum.cz 
Komu: talk-cz@openstreetmap.org
Datum: 10. 5. 2019 16:37:54
Předmět: Re: [talk-cz] Body záchrany Lesy ČR
"

Za mne klidně hned, přes víkend na to bude mít Majka alespoň čas.

Jinak, řešíš i duplicity s highway=emergency_access_point? (asi jo, jenom
pro jistotu připomínám, jelikož tak jsem body záchrany vždy značil já)


On 10. 05. 19 16:06, Jan Macura wrote:

"

P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych tomu aspoň
víkend na vyjádření dalších lidí z komunity.




H.






___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

"
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[xkomc...@centrum.cz]

Za mne klidně hned, přes víkend na to bude mít Majka alespoň čas.

Jinak, řešíš i duplicity s highway=emergency_access_point? (asi jo, 
jenom pro jistotu připomínám, jelikož tak jsem body záchrany vždy značil já)


On 10. 05. 19 16:06, Jan Macura wrote:
P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych tomu 
aspoň víkend na vyjádření dalších lidí z komunity.


H.

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL

[Marek]

Potřeboval bych poradit, podpora mi napsala že potřebuje ikonky ve formátu 
CVG, ale já je mám staženy v BMP a nemůžu přijít na to jak je konvertovat 
na požadovaný formát.

Marek Polák
Rekace od vyvojaru:

Our developers are currently working on a way to more efficiently handle 
gas stations which also have kiosks. The correct behavior should be to 
display the gas station brand icon even if there is the kiosk as well.


For this development, we have created case C2227 and we are looking into 
ways to fix it and improve the behavior. I will let you know as soon as I 
have more info. Safe travels!


mahdi

Vit Semenec via talk-cz wrote on 05/05/2019 01:34 PM:

Ahoj,
nejprve děkuji za odpovědi, přečetl jsem si je hned, ale jak na webu na ně 
odpovědět, je mimo mé schopnosti a do mailu mě to jako v té době 
neregistrovanému  nepřišlo (neměl jsem jak na vlákno odpovědět, jen bych 
nejspíš založil další).


Ještě další příklady:
Ikona benzínky Shell se v Magic Earth nezobrazuje ještě např. zde.   A 
tam je co zadané špatně???

https://www.openstreetmap.org/edit#map=19/50.69258/14.54223
https://www.openstreetmap.org/edit?way=172860536#map=19/50.03445/14.53629

A zde je to OK:
https://www.openstreetmap.org/edit?way=356914203#map=20/50.04682/14.55231
https://www.openstreetmap.org/edit#map=19/49.98401/14.60295

Nemusí být benzinka označená hlavně jako BOD a ne jen jako PLOCHA?


U benzínek, jak právě koukám se na označení plochy budovy náhodně používá 
Čerpací stanice/Obchodní budova/Průmyslová budova/Budova/Budova občanské 
vybavenosti. Ale u většiny je i označena jako bod.


Tady je dokonce jako plocha Benziny vyznačena nejen budova, ale úplně celá 
i zatravněná oblast s parkovištěm:

https://www.openstreetmap.org/edit#map=19/50.22100/15.80720


Moc možností, každý přispěvovatel to pochopí jinak a pak se s daty mají 
aplikace nějak poprat :(


---
Po přečtení příspěvku rekonstrukce multipolygonů, jsem se krapet vyděsil. 
Je toho tolik, co začínající přispěvovatel vůbec netuší a jak snadno 
nevědomky znehodnodnotí práci někoho jiného. Chybí zde funkce nějakého 
zámku, na věci importované z přesného zdroje, nebo takto precizně finálně 
zadané.

---

V.

Dne 05.05.2019 v 10:18 mahdi1234 napsal(a):

cau,

trochu sem se na to dival, a vypada, ze pokud je vyplnen jen "brand", tak 
se ikona nezobrazi, pokud "name" tak jo (zatim to nebudu v osm doplnovat, 
at to muzou spravit v ME).


https://www.openstreetmap.org/way/50734705 - na mape bez ikony
https://www.openstreetmap.org/way/320770862 - na mape s ikonou

zaroven pokud ma tag kiosk, tak se zobrazi na mape nakupni kosik, opet si 
myslim, ze je logictejsi logo site


https://www.openstreetmap.org/node/877762987

Taky pak spolecne s Markem posilame navrh na doplneni ikon prozatim pro 
Benzina, Eurooil, Globus a Makro, klidne dejte navrh pro nakou dalsi vetsi 
sit v CR, co se v ME nezobrazi, poslu to asi ve stredu na svatek.


mahdi

Marek wrote on 05/02/2019 12:14 PM:

Hello Marek,

Thank you for contacting us.

The Magic Earth app has a database with gas station icons which are then 
automatically displayed on the map. You do not need to set up something 
specific in the settings for that.


Can you please give us examples of what gas station icons are not displayed 
and in which locations? Screenshots would be ideal to have.


Also, if you have any other questions or suggestions, we are here to help. 
Safe travels!


Best regards,
Razvan
Marek Polák

Jak pise Marek, mapy cca 2 mesice, ted to chvilu trva kvuli nove bete 
probihaji posledni 3 tydny (bugiku bylo povicero). Po vikendu by mohla byt 
nova verze, takze dalsi update map bude chvili trvat.


Podpora bezne reaguje do dvou pracovnich dnu - supp...@generalmagic.com

mahdi

marek wrote on 04/27/2019 08:07 PM:

Aktualizace ma probíhá cca jednou za 2 měsíce.
Podporu mají, tak jím zkusím napsat.

Marek Polák

__

Od: "Marián Kyral" 
Komu: talk-cz@openstreetmap.org
Datum: 27.04.2019 19:21
Předmět: Re: [talk-cz] Ikonky čerpacích stanic - Shell, OMV, MOL
On 27. 04. 19 11:47, Vit Semenec via talk-cz wrote:
Ahoj,

popisuji jak umím :)

V navigaci Magic Earth se mě u některých benzínek zobrazuje ikonka
konkrétní značky u jiných ne.

Je to tím, že Shell, OMV a MOL mají v iD editoru vlastní skupinu (asi
dle brand:wikidata ?).


Možné to je. Dá se to odhadnout tak, že najdeš jednu benzínku, která
ikonu má a druhou, která ji nemám. Pak se porovnají tagy a chybějící se
dodají. Pak se jen počká, jestli se ta benzínka zobrazí i s ikonou. To
bude ale nějakou dobu trvat. Nevím jak často dělají aktualizaci mapových
dat. Bohužel nemají otevřené kódy, takže se to nedá zjistit analýzou kódu.
Nebo se jich můžeš zeptat. Asi budou mít nějakou podporu.


Uměl by někdo hromadně vyfiltrovat "Čerpací stanice" a ty co mají v
názvu Shell překlopit na typ "Shell Čerpací stanice". A obdobně OMV a MOL?


Ano, uměl ;-)
Začít lze u overpass-turbo.eu: 

Re: [Talk-de] Übersetzung MAPS.ME

[René Falk]

Am 10. Mai 2019 12:35:26 MESZ schrieb Andreas Schmidt 
:
>Ich habe das Wort 'Buchmacher' noch nie gehört. Spontan hätte ich einen
>Handwerksberuf vermutet.

Das verwundert mich zwar, aber das spielt hier keine Rolle. Buchmacher empfinde 
ich eher als eine Bezeichnung für eine Person.

>'Wettbüro' ist hier in Norddeutschland m.E. viel gebräuchlicher. 

Finde ich als Norddeutscher eigentlich nicht, aber Wettbüro finde ich 
sprachlich korrekter für ein Geschäft.

>Synonym
>nutze ich 'Sportwetten' (als Gebäudebezeichnung).

Nicht gut. Es könnten ja auch mal andere Arten von Wetten angeboten werden und 
vielleicht ändert sich das in Deutschland irgendwann mal. Eine allgemeinere 
Bezeichnung fände ich besser. Bei Bedarf kann man einen Tag für Spezifikationen 
einrichten, falls mal was anderes als Sportwetten angeboten wird. Was ist an 
Wettbüro auch als Gebäudebezeichnung falsch?

>Andere Wetten, wie z.B. der Babyname der Königsfamilie haben hier wohl
>nur ein Nischendasein.

Nischen sind doch das Salz in der OSM-Suppe. :)

Grüße
René


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

P.S. Ani nyní bych se nehrnul do žádné hurá akce a nechal bych tomu aspoň
víkend na vyjádření dalších lidí z komunity.

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

Hlasuji pro smazani name. Takze by melo zustat:

emergency=access_point
emergency_telephone_code=112
operator=Lesy ČR, s.p.
ref=RA028

jen pro jistotu:

https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy ČR
https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy%20%C4%8CR%2C%20s.p.
https://taginfo.openstreetmap.cz/tags/?key=operator=Lesy%20%C4%8CR%20a.s.

za mne asi ten s.p. je nejvhodnejsi.

Diky moc.

pá 10. 5. 2019 v 15:42 odesílatel Majka  napsal:
>
> No, já osobně bych to vymazala. Ten hlavní tag totiž neříká nic jiného... 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] STRUTTURE DI ARRAMPICATA

[Geometra Alberto VARALLI]

Perfetto, l'unico problema è che così facendo la falesia non viene
visualizzata sulla mappa se non dopo l'interrogazione.
Ho visto che in alcuni casi viene inserito anche il tag "viewpoint" per
visualizzare un asterisco che individua il punto.

Può essere corretto?


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno ven 10 mag 2019 alle ore 14:15 Giacomo Innocenti <
jacktheb...@gmail.com> ha scritto:

> io personalmente in una falesia naturale procedo così:
> creo l area e aggiungo i tag (come minimo):
>
> climbing:grade:french:max
> climbing:grade:french:min
> climbing:orientation
> climbing:sport
>
> natural cliff
> sport climbing
> leisure pitch
> name
>
>
> si potrebbe mappare anche le singole vie teoricamente, ma nella maggior
> parte dei casi risulterebbe a dir poco confusionario e di difficile se non
> impossibile rappresentazione.
>
> Il giorno ven 10 mag 2019 alle ore 13:00 Geometra Alberto VARALLI <
> geom.vara...@gmail.com> ha scritto:
>
>> Buongiorno a tutti, vi pongo un quesito legato al mondo dell'arrampicata
>> sportiva.
>>
>> In particolare mi chiedo come devono essere inserite:
>> - falesie di arrampicata naturale all'aperto;
>> - massi naturali all'aperto (boulder) per l'arrampicata;
>>
>> Sui singoli tag vi è un'apposita pagina del wiki che vi inserisco
>>
>> https://wiki.openstreetmap.org/wiki/Climbing
>>
>> Grazie per l'aiuto
>>
>>
>> 
>>  Mail
>> priva di virus. www.avast.com
>> 
>> <#m_7140016636583724090_m_-8236079056184823132_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>


-- 

-- 

*Geom. Alberto Varalli*

Sede: Via Roma  n. 13/c, 10070 Usseglio (TO)

Cell. 348-5400147 -o- @mail: geom.vara...@gmail.com

P.I.V.A.: 10645110015

Tutte le informazioni contenute in questo messaggio, incluso ogni allegato,
sono di carattere confidenziale e possono essere legalmente riservate. Sono
destinate  ad uso esclusivo del ricevente ed ogni divulgazione, copia,
distribuzione o riferimento è proibito e può essere considerato illegale.
Se tale messaggio è stato ricevuto per errore, il mittente deve esserne
prontamente avvisato ed il messaggio deve essere distrutto, compreso ogni
allegato presente.

La trasmissione via posta elettronica non può essere ritenuta sicura o
priva di errori, in quanto le informazioni potrebbero essere intercettate,
danneggiate, smarrite, distrutte, arrivare in ritardo o incomplete, oppure
contenere virus informatici. Per queste ragioni il mittente non si ritiene
responsabile per errori od omissioni nel contenuto di questo messaggio che
deriva da una trasmissione via posta elettronica. Se si rendesse
necessaria una verifica formale sul contenuto di questo messaggio siete
pregati di richiederne una copia cartacea.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Mikel Maron]

> I believe the issue is more about the unwillingness to take community 
> feedback seriously at all when it doesn't coincide with the opinions already 
> held by the developers. Which brings us back full circle to the discussion of 
> the privileged position of the default editor on openstreetmap.org and the 
> related transparency (aka who is holding the purse strings) and the 
> non-existent community control or even just control by the OSMF.

This is a very interesting paragraph, dense with deep topics for the OSM 
project. These topics should separate this from the particulars of individual 
situations, because the dynamics are not unique to any single component of the 
OSM data and software ecosystem. OSM has always been a muddle and arguably one 
of the reasons for its success. In OSM people disagree, there's strong points 
of view and discussion, sometimes it resolves, often times we continue to 
muddle through. Yes, the OSMF has ultimately legal authority over all aspects 
of the project but by design and history, exercises it very selectively. And 
community is a very amorphous concept, with disagreements over what that means 
and how it functions. 
Certainly the shape of the OSM project has outgrown the systems we haphazardly 
put in place for governance and community back in 2007. It's worth stepping 
back from many of the recent heated issues in the community, and look at how 
they are the result of growth without intentional adaptation, and consider what 
kind of approach we can take to imagine what OSM is like in the next 15 years.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole  
wrote:  
 
  

 
 Am 09.05.2019 um 23:14 schrieb Mikel Maron:
  
 
> What do you think? Should the next version of iD be deployed on 
www.openstreetmap.org?  
  Absolutely. My understanding is this feature will greatly improve data 
quality in OSM. I think it's fair to validate squareness of existing buildings. 
Appreciate the great work of the iD team.  

The question was not about validating square or not square buildings, it is 
about storing a hint for iDs validation mechanism permanently in OSMs data. 
There is some precedent for doing so, as was mentioned in the github issue, 
still it is a bit controversial and discussion when adding such a feature 
should be expected. 
 
 
[Rant on the massively overrated concern for buildings in the first place and 
the background why people think that such a validation is necessary omitted]
 
   Also commend your attention to tagging issues Michael. There's certainly a 
broader issue with how tags are managed in OSM. In short it's a mess all around 
and is in need of a rethink. I don't think this minor issue is a "hill to die 
on" however.   
 
I believe the issue is more about the unwillingness to take community feedback 
seriously at all when it doesn't coincide with the opinions already held by the 
developers. Which brings us back full circle to the discussion of the 
privileged position of the default editor on openstreetmap.org and the related 
transparency (aka who is holding the purse strings) and the non-existent 
community control or even just control by the OSMF.
 
 
Simon

  
   
  -Mikel 
  * Mikel Maron * +14152835207 @mikel s:mikelmaron  
  
  On Thursday, May 9, 2019, 4:18:20 PM EDT, Michael Reichert 
 wrote:  
  
   Hi,
  
  this could be seen as a tagging discussion but I think that it is a
  discussion on governance and power. That's why this email goes to the
  Talk mailing list.
  
  Quincy Morgan, one of the maintainers of iD, invented a new tag called
  nosquare=yes today which should be added to buildings which are not
  square and should not be flagged by iD's validator. I (and later Paul
  Norman) pointed out issues with the tag. I asked Quincy to discuss the
  addition with the wider community beforehand.
  
  https://github.com/openstreetmap/iD/issues/6332
  
  Here are the issues I pointed out in the bugtracker. At the beginning he
  planned to use square=no which he later changed to nosquare=yes but this
  change does not make things better:
  > Although noname=yes is common, it is not that common that it can serve as 
an argument in favour of introducing unsquare=yes. In difference to noexit=yes, 
unsquare=yes and noname=yes only serve as a workaround for quality assurance 
tools. noexit=yes also conveys information for map users: There road ends here.
  > 
  > Some people prefer to tag as complete as possible and add oneway=no, 
cycleway=no, lit=no etc. to any way. However, such a practice is not base on a 
broad consensus and if you dig deep enough in the history of user blocks in 
OSM, you might find blocks set due to an excessive use of negative binary tags.
  > 
  > I think that iD does not need this tag and should only validate buildings 
if they have been added or modified in the current session. If doing so, they 
will be reported once which does not 

Re: [talk-cz] Body záchrany Lesy ČR

[Majka]

No, já osobně bych to vymazala. Ten hlavní tag totiž neříká nic jiného... ___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Jan Macura]

On Fri, 10 May 2019 at 15:32, Majka  wrote:

> Takže v datech vyhodit x;y;name
>
> Co s tím name? Dát do note?
>

Co je v name bych dal do description. Note je dočasná značka.

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Majka]

udělán revert 

Připravím import

Takže v datech vyhodit x;y;name

Co s tím name? Dát do note?
Navíc už podobně máme některé ve FM.

Pak to můžu sloučit a znova nahrát.


Majka

10. května 2019 10:43:00 SELČ, Tom Ka  napsal:
>OK, ja se k tomu dostanu nekdy vecer spis az v Po, je to na dyl.
>Jestli budes mit cas, za mne prosi udelej to.
>
>Diky
>
>pá 10. 5. 2019 v 8:42 odesílatel Majka 
>napsal:
>>
>> Jsem taky pro revert.
>> Snaha pořešit duplicity tam byla dodatečně po tom mailu, v noci jsem
>viděla dvě sady změn, které je mazaly. Takže revert bude trochu
>náročnější, zvlášť pokud tam přistálo něco dalšího.
>>
>> Jako úmysl 1*, ale provedení tak 4-
>>
>> 10. května 2019 8:11:33 SELČ, Tom Ka 
>napsal:
>>>
>>> Ahoj, data jsou super ale skoro bych v tomhle pripade udelal revert
>na
>>> tu sadu zmen at se nedelaji kolize - podle toho, co jsem se koukal,
>to
>>> vubec neresi duplicity. Pak bych z te sady zmen udelal seznam pro
>>> nasledny import jedne jednou a poradne pote, co bude nejak dolozen
>>> souhlas Lesu CR. Co vy na to?
>>>
>>> Bye
>>>
>>> čt 9. 5. 2019 v 23:36 odesílatel Majka 
>napsal:
>>> >

  Souhlasím se vším uvedeným, jen source se aktuálně doporučuje (na
>import listu) jen na sadě změn, kde je uvedený.

  To ostatní všechno vyplývá z bodu jedna - každý import je třeba
>projednat tady a minimálně oznámit na import listu. Na 90% se proti
>tomu někdo ozve, tohle bude jednoznačně flagnuto jako nedovolený import
>a rozsahem to nezapadne.

  9. května 2019 23:28:05 SELČ, Jan Macura 
>napsal:
>
>  Také zdravím,
>
>  určitě díky za pěkné obohacení OSM a zařízení souhlasu od
>instituce! (btw, nebyl by písemně?)
>
>  Mám ale několik připomínek, které mi kazí radost...
>
>  Kde je souhlas komunity OSM s importem? Jak byly řešeny
>vzniknuvší duplicity v datech? Jak byly vybrány použité tagy? Proč jsou
>u bodů uvedeny souřadnice jako tagy X a Y? Proč mají všechny body
>"name=Bod záchrany - Rescue Point" navzdory všem doporučením o tom, co
>by mělo být obsahem klíče name? Proč není uveden zdroj dat v klíči
>source? Jaká je přesnost dat? Jak budou data udržována aktuální? Atd.
>...
>
>  Aspoň, že je vše nahráno v jedné snadno dohledatelné sadě změn!
>   H.
>
>  On Thu, 9 May 2019 at 22:53, Spratek  wrote:
>>
>>  Zdravím,
>>  se souhlasem Lesů ČR jsem na OSM nahrál kompletní seznam Bodů
>záchrany spravovaných Lesy ČR.
>>  Celkem jich je 2171.
>>  Přehledná mapka bodů je zde:
>> 
>https://commons.wikimedia.org/wiki/File:Body_z%C3%A1chrany_-_Lesy_%C4%8CR.jpg
>>
>>  Doufám, že jich bude potřeba co nejmíň.
>>  Míru zdar.
>> 
>>  talk-cz mailing list
>>  talk-cz@openstreetmap.org
>>  https://lists.openstreetmap.org/listinfo/talk-cz
>>  https://openstreetmap.cz/talkcz

 
 talk-cz mailing list
 talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz
 https://openstreetmap.cz/talkcz
>>>
>>> 
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>
>___
>talk-cz mailing list
>talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Modif majeure merdique

[Vincent Bergeot]

Le 10/05/2019 à 12:14, osm.sanspourr...@spamgourmet.com a écrit :
Par contre se pose la question de la source de cette modification : 
vraiment relevé sur le terrain ? Celui qui a déjà échangé avec 
l'auteur peut peut-être lui poser la question car si la source c'est 
l'IGN ça n'est pas bon.


Bonjour,

voici ce que m'a répondu l'auteur :

"J'ai pas mal arpenté les environs. Les lieux nommés sont bons, usités 
par les gents du crû (agriculteur, forestier...) confirmés soit par 
geoportail

soit IGN. "

difficile de savoir !

--
Vincent Bergeot


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Modif majeure merdique

[Rpnpif]

Le 10 mai 2019, osm.sanspourr...@spamgourmet.com a écrit :

> Le 10/05/2019 à 10:38, Rpnpif - rpn...@trob.eu a écrit :
> > Par ailleurs, ce n'est pas parce qu'il n'y a pas de panneau sur le
> > lieu et que ces noms sont « introuvables sur le terrain », même pour une
> > simple parcelle, qu'ils ne sont pas utilisés.
> >
> > Je connais de très nombreux cas ainsi où ces noms permettent de repérer
> > des parcelles ou lieux-dits inhabités (locality) utiles pour les PLU,
> > actes notariaux, ou simplement pour des riverains, propriétaires,
> > exploitants qui les utilisent oralement. Même si les plus jeunes
> > d'entre eux les oublient parfois ou ne les connaissent pas.
> >
> > -- Alain Rpnpif  
> 
> Ça permet aussi que la mairie ou le promoteur s'en inspire pour donner
> un nom à une rue, un lotissement...
> 
> Bref, c'est utile de le renseigner dans OSM.
> 
> Par contre se pose la question de la source de cette modification :
> vraiment relevé sur le terrain ? Celui qui a déjà échangé avec l'auteur
> peut peut-être lui poser la question car si la source c'est l'IGN ça
> n'est pas bon.
> 
> Jean-Yvon
> 

Cela peut être BANO.

-- 
Alain Rpnpif

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Dataset českých názvů v OSM

[Jan Macura]

Zdravím,

něčo také: http://overpass-turbo.eu/s/ISu ? Na celou ČR to bylo trochu moc
dat najednou a server odmítnul požadavek zpracovat, ale rozdělit si to na
14 datových sad po jednotlivých krajích by možná bylo pro popisovaný účel i
přehlednější.

H.

On Fri, 10 May 2019 at 14:17, František Pfann 
wrote:

> Zdravím, snažím se analyzovat část české literatury konce 19. století, co
> se týče místních názvů - pracuji s OCR daných knih. Už mám vyexportovány
> všechny vlastní jména, ale teď bych je potřeboval popárovat s místními
> názvy, které v sobě mají OSM. Napadá vás, jak se k podobnému souboru názvů
> (prozatím nepotřebuji jejich souřadnice a další data) dostat? Podobně jako
> jsem si tady třeba stáhl názvy všech článků na wikipedii -
> https://dumps.wikimedia.org/cswiki/latest/?fbclid=IwAR3Bd0UvsQFuxf90Ncp9t7YBe7dRbyT6XE70llYip9KW9MIk9MLux85UXGg
> .
> Díky moc za radu.
> František
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Dataset českých názvů v OSM

[Miroslav Suchy]

Dne 10. 05. 19 v 13:44 František Pfann napsal(a):
> s místními názvy,

Co přesně si představujete pod "místním názvem"? Tohle

https://wiki.openstreetmap.org/wiki/Cs:Tag:place%3Dlocality

tj. "za humny", "na bahnech"

nebo názvy obcí/rybníků apod.?

Mirek

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Dataset českých názvů v OSM

[František Pfann]

Zdravím, snažím se analyzovat část české literatury konce 19. století, co
se týče místních názvů - pracuji s OCR daných knih. Už mám vyexportovány
všechny vlastní jména, ale teď bych je potřeboval popárovat s místními
názvy, které v sobě mají OSM. Napadá vás, jak se k podobnému souboru názvů
(prozatím nepotřebuji jejich souřadnice a další data) dostat? Podobně jako
jsem si tady třeba stáhl názvy všech článků na wikipedii -
https://dumps.wikimedia.org/cswiki/latest/?fbclid=IwAR3Bd0UvsQFuxf90Ncp9t7YBe7dRbyT6XE70llYip9KW9MIk9MLux85UXGg
.
Díky moc za radu.
František
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] STRUTTURE DI ARRAMPICATA

[Giacomo Innocenti]

io personalmente in una falesia naturale procedo così:
creo l area e aggiungo i tag (come minimo):

climbing:grade:french:max
climbing:grade:french:min
climbing:orientation
climbing:sport

natural cliff
sport climbing
leisure pitch
name


si potrebbe mappare anche le singole vie teoricamente, ma nella maggior
parte dei casi risulterebbe a dir poco confusionario e di difficile se non
impossibile rappresentazione.

Il giorno ven 10 mag 2019 alle ore 13:00 Geometra Alberto VARALLI <
geom.vara...@gmail.com> ha scritto:

> Buongiorno a tutti, vi pongo un quesito legato al mondo dell'arrampicata
> sportiva.
>
> In particolare mi chiedo come devono essere inserite:
> - falesie di arrampicata naturale all'aperto;
> - massi naturali all'aperto (boulder) per l'arrampicata;
>
> Sui singoli tag vi è un'apposita pagina del wiki che vi inserisco
>
> https://wiki.openstreetmap.org/wiki/Climbing
>
> Grazie per l'aiuto
>
>
> 
>  Mail
> priva di virus. www.avast.com
> 
> <#m_-8236079056184823132_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Martin Koppenhoefer]

scusate per la ripetizione, mi caricava le altre risposte soltanto dopo che 
avevo già mandato o_O

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 09:55, Tatti Barletta  wrote:
> 
> controllando le modifiche recenti nella mia città, ho notato che sono
> presenti diverse rotatorie "aperte", ossia formate da più segmenti
> invece che da un percorso unico.


più segmenti invece del percorso unico dovrebbe essere ok, invece “aperte” (non 
chiuse) sarebbe un’errore.


> Ciò
> rompe il comportamento di alcuni servizi di routing [2], i quali non
> sono più in grado di stabilire che ci si trova all'interno di una
> rotatoria e fornire di conseguenza indicazioni accurate.


segnalerei il problema a loro, forse lo fissano.

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Cartes historiques

[Jérôme Amagat]

ça n'a pas grand chose à voir avec cette discussion mais je le rappelle car
on voit bien le problème sur cette carte :

le tag historic=monument ne veux pas dire que c'est un monument historique
voir la page du wiki :
https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Dmonument
il y a plus de 3000 tag historic=monument en france d’après taginfo, c'est
beaucoup trop. https://taginfo.openstreetmap.fr/tags/historic=monument

historic=monument doit être utilisé pour les grands monuments "monumentaux"
souvent commémoratifs comme l'arc de triomphe.
Pour de petits monuments commémoratifs il y a le tag historic=memorial
sinon pour d'autres "choses" qui ont un intérêt historique, il faut
utiliser une autre valeur pour historic=*
comme historic=church, castle ... et si on n'a pas d’idée utiliser
historic=yes
il y a une liste ici : https://wiki.openstreetmap.org/wiki/FR:Key:historic
mais rien n'interdit d'être créatif.

Il devrait y avoir très peu de historic=monument donc si certains veulent
supprimer de ce tag pour le remplacer par autres chose, ne vous gênez pas.
la requête overpass turbo pour les trouver :
https://overpass-turbo.eu/s/ISf
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] STRUTTURE DI ARRAMPICATA

[Geometra Alberto VARALLI]

Buongiorno a tutti, vi pongo un quesito legato al mondo dell'arrampicata
sportiva.

In particolare mi chiedo come devono essere inserite:
- falesie di arrampicata naturale all'aperto;
- massi naturali all'aperto (boulder) per l'arrampicata;

Sui singoli tag vi è un'apposita pagina del wiki che vi inserisco

https://wiki.openstreetmap.org/wiki/Climbing

Grazie per l'aiuto


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Übersetzung MAPS.ME

[Andreas Schmidt]

Ich habe das Wort 'Buchmacher' noch nie gehört. Spontan hätte ich einen
Handwerksberuf vermutet.
'Wettbüro' ist hier in Norddeutschland m.E. viel gebräuchlicher. Synonym
nutze ich 'Sportwetten' (als Gebäudebezeichnung).

Andere Wetten, wie z.B. der Babyname der Königsfamilie haben hier wohl
nur ein Nischendasein.

Am 10.05.19 um 10:44 schrieb nmx...@web.de:
> Hallo,
>
> ich habe die deutschen Übersetzungen von MAPS.ME durchgeguckt und meinen 
> Verständnis nach durch genauere Begriffe angepasst [1].
> Anlass dazu war, dass ich mich an dem Begriff "Buchmacher" gestört habe, für 
> den ich "Wettbüro" angemessener finde. 
> Obwohl ich inzwischen darauf hingewiesen wurde, dass "Buchmacher" durchaus 
> richtig ist[2][3], spreche ich mich für den Begriff "Wettbüro" aus, da es mMn 
> weiter verbreitet ist.
>
> Kann das bitte jemand Korrektur lesen, bevor ich dazu einen Pull-Request 
> erstelle? Ich freue mich auf Feedback jeder Art - inklusive “Alles Ok”. ;-)
>
>
> Vielen Dank und viele Grüße
> Nmxosm
>
> [1]https://github.com/mapsme/omim/compare/master...nmxcgeo:master
> [2]https://www.openstreetmap.org/user/Nmxosm/diary/152901
> [3]https://wiki.osm.org/wiki/DE:Tag:shop%3Dbookmaker
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Cartes historiques

[osm . sanspourriel]

Sur la page en haut à droite, dans contact figure :

lutz@historic.place

Comme c'est sur la page en Français avec un peu de chance cette personne
parle français.

Oui tu n'as pas bien cherché^^.

Jean-Yvon

Le 10/05/2019 à 11:35, Dlareg - dla...@dlareg.org a écrit :

Le 10/05/2019 à 11:23, Vincent Bergeot a écrit :

Je n'ai pas trouvé de moyen de faire remonter cette info, peut-être
qu'ici il y a des gens impliqués dans le projet ?


https://wiki.openstreetmap.org/wiki/User:Zecke

Kontakt

Am einfachsten erreicht man mich per Email unter Zeckem CHEZ historic.place

Beim Fratzenbuch kann man mich finden als: "Osm Zecke"


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Modif majeure merdique

[osm . sanspourriel]

Le 10/05/2019 à 10:38, Rpnpif - rpn...@trob.eu a écrit :

Par ailleurs, ce n'est pas parce qu'il n'y a pas de panneau sur le
lieu et que ces noms sont « introuvables sur le terrain », même pour une
simple parcelle, qu'ils ne sont pas utilisés.

Je connais de très nombreux cas ainsi où ces noms permettent de repérer
des parcelles ou lieux-dits inhabités (locality) utiles pour les PLU,
actes notariaux, ou simplement pour des riverains, propriétaires,
exploitants qui les utilisent oralement. Même si les plus jeunes
d'entre eux les oublient parfois ou ne les connaissent pas.

-- Alain Rpnpif


Ça permet aussi que la mairie ou le promoteur s'en inspire pour donner
un nom à une rue, un lotissement...

Bref, c'est utile de le renseigner dans OSM.

Par contre se pose la question de la source de cette modification :
vraiment relevé sur le terrain ? Celui qui a déjà échangé avec l'auteur
peut peut-être lui poser la question car si la source c'est l'IGN ça
n'est pas bon.

Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Tag presenti in Italia

[Ivo Reano]

Bellissimo!
building=yess
e
building=yes?

Mi fanno proprio godere/ridere
highway=wayside_shrine
l'avevo già trovato a Saint Marcel (stavo cazzeggiando mentre aspettavo
iniziasse la riunione dei valdostani); conseguenza credo di un nome di via
diventato tag. Magari me ne è scappato uno.

natural=couloir
di sicuro è un francese, un italiano avrebbe scritto
natural=canalino

I tag con una sola occorrenza nella chiave natural mi fanno pensare che
molti non capiscono che natural significa naturale ovvero l'opposto di
man_made/fatto dall'uomo

Scherzi a parte...
Come faccio a controllare la mia zona?
Non posso mica scaricare 1/3 della provincia di Torino e poi cercare su
josm le voci singole.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Cartes historiques

[Dlareg]

Le 10/05/2019 à 11:23, Vincent Bergeot a écrit :
> Je n'ai pas trouvé de moyen de faire remonter cette info, peut-être
> qu'ici il y a des gens impliqués dans le projet ?
> 

https://wiki.openstreetmap.org/wiki/User:Zecke

Kontakt

Am einfachsten erreicht man mich per Email unter Zeckem CHEZ historic.place

Beim Fratzenbuch kann man mich finden als: "Osm Zecke"

-- 
Dlareg



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Übersetzung MAPS.ME

[Hauke Stieler]

Moin,

finde ich sehr gut, dass du da mal drüber geschaut hast.

Eine Anmerkung und Frage habe ich aber:

* Ich hätte "Installateur" nicht zwingend ersetzt, stattdessen eher
"Klempner" hinzugefügt. Kenne Leute, die das Wort "Installateur"
durchaus eher nutzen.

* Gibt es einen Grund, warum du z.B. "motorway.tunnel" nicht mit
"Autobahntunnel" übersetzt hast?

Ansonsten passt das aus meiner Sicht.

Viele Grüße
Hauke

PS.: Ich finde es gut, dass du "historic.tomb" von "Attraktion" zu
"Grabstätte" geändert hast. Dein Vorgänger hatte wohl eine menge
schwarzen Humor :D

On 10.05.19 10:44, nmx...@web.de wrote:
> Hallo,
> 
> ich habe die deutschen Übersetzungen von MAPS.ME durchgeguckt und meinen 
> Verständnis nach durch genauere Begriffe angepasst [1].
> Anlass dazu war, dass ich mich an dem Begriff "Buchmacher" gestört habe, für 
> den ich "Wettbüro" angemessener finde. 
> Obwohl ich inzwischen darauf hingewiesen wurde, dass "Buchmacher" durchaus 
> richtig ist[2][3], spreche ich mich für den Begriff "Wettbüro" aus, da es mMn 
> weiter verbreitet ist.
> 
> Kann das bitte jemand Korrektur lesen, bevor ich dazu einen Pull-Request 
> erstelle? Ich freue mich auf Feedback jeder Art - inklusive “Alles Ok”. ;-)
> 
> 
> Vielen Dank und viele Grüße
> Nmxosm
> 
> [1]https://github.com/mapsme/omim/compare/master...nmxcgeo:master
> [2]https://www.openstreetmap.org/user/Nmxosm/diary/152901
> [3]https://wiki.osm.org/wiki/DE:Tag:shop%3Dbookmaker
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Cartes historiques

[Vincent Bergeot]

Le 10/05/2019 à 11:32, marc marc a écrit :

Le 10.05.19 à 11:23, Vincent Bergeot a écrit :

http://gk.historic.place/historische_objekte/translate/fr/index-fr.html
Je n'ai pas trouvé de moyen de faire remonter cette info

j'ai trouvé 3 moyens de contact
https://wiki.openstreetmap.org/wiki/Historical_Objects#Opinions.2C_Suggestions.2C_Discussion



merci :) pas bien cherché du coup :(





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
Vincent Bergeot


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartes historiques

[marc marc]

Le 10.05.19 à 11:23, Vincent Bergeot a écrit :
> http://gk.historic.place/historische_objekte/translate/fr/index-fr.html
> Je n'ai pas trouvé de moyen de faire remonter cette info

j'ai trouvé 3 moyens de contact
https://wiki.openstreetmap.org/wiki/Historical_Objects#Opinions.2C_Suggestions.2C_Discussion
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Cartes historiques

[Vincent Bergeot]

Bonjour,

j'ai découvert 
http://gk.historic.place/historische_objekte/translate/fr/index-fr.html


Cependant, erreur sur des liens :

 * exemple :
   
http://gk.historic.place/historische_objekte/translate/fr/index-fr.html?zoom=19=44.8379=-0.56713=w80044733=HaHbHcSaHe
 * Quand on cherche à aller sur le lien Culture.gouv.fr, il y a une erreur:
 o 
https://www.culture.gouv.fr/public/mistral/mersri_fr?ACTION=CHERCHER_1=REF_1=PA00083349
 * en passant par wikidata, j'arrive à une url correcte qui est :
 o 
http://www2.culture.gouv.fr/public/mistral/merimee_fr?ACTION=CHERCHER_1=REF_1=PA00083349

Je n'ai pas trouvé de moyen de faire remonter cette info, peut-être 
qu'ici il y a des gens impliqués dans le projet ?


Bonne journée

--
Vincent Bergeot

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Borne Michelin

[marc marc]

Le  8 mai 2019, Gwenaël Jouvin via Talk-fr a écrit :
> date de fabrication et date de mise en service sont différentes
> Dans ce genre de cas, la date de mise en service est inconnue.

ce qui me faisait réagir c'est "fabriquer une pierre" (= la formation 
géologique), enfin bref c'est du détail.
Mais il y a une source qui dit que la date connue n'est pas celle
de mise en service ? j'ai du mal à croire que quelqu'un a taillé/peint
une borne, l'ai gardé des années dans un coin pour ne l'utiliser
que + tard. c'est en cela que je réagissais aux différents _date :
ne pas en arriver à ce que l'un dise que c'est pas la date de mise
en service mais celle de fabrication, un autre dira que c'est la date
de la commande, un autre dira que c'est la date de l'inauguration...
alors que travailler sur des éléments aussi vieux a une précision
très relative, hormis les cas où c'est écrit sur l'élément
(c'est ce que tu avais évoqué pour les abribus)

Le 10.05.19 à 10:42, Rpnpif a écrit :
> Par contre, name=Ancienne borne Michelin ne convient pas 
> car c'est plutôt une description que le nom.

ce n'est en effet pas un nom.
mais cela mériterait sans doute d'être structuré dans un tag.
Michelin était-il le fabriquant et/ou l'opérateur ?
qlq chose genre manufacter=Michelin ou was:operator=Michelin
permettrait aux passionnés de les retrouver.
voir de leur proposer d'intégrer leur bdd dans osm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Florian Lohoff]

Hola,

On Thu, May 09, 2019 at 06:00:20PM -0400, Jmapb wrote:
> This strikes me as a pretty bad idea. I map in NYC where we have lots,
> lots, lots of nearly-square buildings with official footprints imported
> from the city's open data initiative. When a mapper not familiar with
> the history here gets a message from iD (which, to many mappers, is
> indistinguishable from getting a message from OSM itself) encouraging
> them to square a building, they'll do it because it seems like the right
> thing to do. So the official, highly-accurate footprints are lost. And
> adjacent buildings with shared nodes are also distorted.

I agree on this. Its a bad idea for nearly square buildings to complain 
on them. Not everying is 90° - Not even in Germany where we love
rectangular things.

But the point is that i'd like a generic way to to qa/validation
hinting. I just sent a similar mail in in a similar thread on the 
German mailinglist.

I'd like to see qa/validation hinting tags be more organised:

qa:rectangular=no
qa:exit=no
qa:name=no
qa:housenumber=no

or the list form:

validation_hint=noexit;noname;norectangular;nohousenumber

So every validator could have the "suppress check XYZ" on this object.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Rotatorie aperte

[Volker Schmidt]

Annotazione:
ci sono rotonde "spezzate" anche a causa di route per bicicletta che
secondo la direzione fanno una o l'altra parte della rotonda.
Ne ho inserite parecchie di questo tipo.

On Fri, 10 May 2019 at 10:36, Tatti Barletta  wrote:

> Il giorno ven, 10/05/2019 alle 10.23 +0200, Lorenzo Beltrami ha
> scritto:
> > Nel caso specifico sono sbagliati i dati su OSM. La rotonda non aveva
> > il
> > tag "junction=roundabout" (ora l'ho inserito, bisogna aspettare che
> > il
> > router si aggiorni).
>
> Grazie mille, non avevo proprio notato il problema! :o
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-de] QA annotation/hinting Was: iD führt nosquare=yes für nicht rechtwinklige Gebäude ein (WAS: Besorgt über den iD-Editor)

[Florian Lohoff]

Hola,

On Fri, May 10, 2019 at 09:56:11AM +0200, Martin Koppenhoefer wrote:
> > On 9. May 2019, at 22:55, Michael Reichert  wrote:
> > 
> > Wenn ihr eine Meinung zu der Sache habt, egal welche, steht es euch
> > natürlich frei, euch auf GitHub, auf dieser Mailingliste oder auf der
> > Mailingliste Talk zu äußern.
> 
> 
> Danke für Deinen Einsatz, ich sehe das Monieren von nicht
> rechtwinkligen Gebäuden auch als Problem und von daher auch den tag
> als kritisch.
> 
> (im Gegensatz übrigens zu noname und dem neuen nohousenumber)

Ich würde da gerne eine generische Debatte sehen zu object annotation
für die validation/qa tools. Und ich fände es nicht schlecht
das ganz klar in eine Hierarchie zu gliedern um deutlich zu machen
das es hier nur um annotation/hinting für die Validatoren geht. In das
noexit wird immer viel rein interpretiert.

qa:rectangular=no
qa:exit=no
qa:name=no
qa:housenumber=no

Oder es als Liste ausprägen - Am ende werden ja nicht so viele
validation hinting je Objekt hinterlegt werden müssen.

validation_hint=noexit;noname;norectangular;nohousenumber

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Übersetzung MAPS.ME

[nmxosm]

Hallo,

ich habe die deutschen Übersetzungen von MAPS.ME durchgeguckt und meinen 
Verständnis nach durch genauere Begriffe angepasst [1].
Anlass dazu war, dass ich mich an dem Begriff "Buchmacher" gestört habe, für 
den ich "Wettbüro" angemessener finde. 
Obwohl ich inzwischen darauf hingewiesen wurde, dass "Buchmacher" durchaus 
richtig ist[2][3], spreche ich mich für den Begriff "Wettbüro" aus, da es mMn 
weiter verbreitet ist.

Kann das bitte jemand Korrektur lesen, bevor ich dazu einen Pull-Request 
erstelle? Ich freue mich auf Feedback jeder Art - inklusive “Alles Ok”. ;-)


Vielen Dank und viele Grüße
Nmxosm

[1]https://github.com/mapsme/omim/compare/master...nmxcgeo:master
[2]https://www.openstreetmap.org/user/Nmxosm/diary/152901
[3]https://wiki.osm.org/wiki/DE:Tag:shop%3Dbookmaker

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

OK, ja se k tomu dostanu nekdy vecer spis az v Po, je to na dyl.
Jestli budes mit cas, za mne prosi udelej to.

Diky

pá 10. 5. 2019 v 8:42 odesílatel Majka  napsal:
>
> Jsem taky pro revert.
> Snaha pořešit duplicity tam byla dodatečně po tom mailu, v noci jsem viděla 
> dvě sady změn, které je mazaly. Takže revert bude trochu náročnější, zvlášť 
> pokud tam přistálo něco dalšího.
>
> Jako úmysl 1*, ale provedení tak 4-
>
> 10. května 2019 8:11:33 SELČ, Tom Ka  napsal:
>>
>> Ahoj, data jsou super ale skoro bych v tomhle pripade udelal revert na
>> tu sadu zmen at se nedelaji kolize - podle toho, co jsem se koukal, to
>> vubec neresi duplicity. Pak bych z te sady zmen udelal seznam pro
>> nasledny import jedne jednou a poradne pote, co bude nejak dolozen
>> souhlas Lesu CR. Co vy na to?
>>
>> Bye
>>
>> čt 9. 5. 2019 v 23:36 odesílatel Majka  napsal:
>> >
>>>
>>>  Souhlasím se vším uvedeným, jen source se aktuálně doporučuje (na import 
>>> listu) jen na sadě změn, kde je uvedený.
>>>
>>>  To ostatní všechno vyplývá z bodu jedna - každý import je třeba projednat 
>>> tady a minimálně oznámit na import listu. Na 90% se proti tomu někdo ozve, 
>>> tohle bude jednoznačně flagnuto jako nedovolený import a rozsahem to 
>>> nezapadne.
>>>
>>>  9. května 2019 23:28:05 SELČ, Jan Macura  napsal:

  Také zdravím,

  určitě díky za pěkné obohacení OSM a zařízení souhlasu od instituce! 
 (btw, nebyl by písemně?)

  Mám ale několik připomínek, které mi kazí radost...

  Kde je souhlas komunity OSM s importem? Jak byly řešeny vzniknuvší 
 duplicity v datech? Jak byly vybrány použité tagy? Proč jsou u bodů 
 uvedeny souřadnice jako tagy X a Y? Proč mají všechny body "name=Bod 
 záchrany - Rescue Point" navzdory všem doporučením o tom, co by mělo být 
 obsahem klíče name? Proč není uveden zdroj dat v klíči source? Jaká je 
 přesnost dat? Jak budou data udržována aktuální? Atd. ...

  Aspoň, že je vše nahráno v jedné snadno dohledatelné sadě změn!
   H.

  On Thu, 9 May 2019 at 22:53, Spratek  wrote:
>
>  Zdravím,
>  se souhlasem Lesů ČR jsem na OSM nahrál kompletní seznam Bodů záchrany 
> spravovaných Lesy ČR.
>  Celkem jich je 2171.
>  Přehledná mapka bodů je zde:
>  
> https://commons.wikimedia.org/wiki/File:Body_z%C3%A1chrany_-_Lesy_%C4%8CR.jpg
>
>  Doufám, že jich bude potřeba co nejmíň.
>  Míru zdar.
> 
>  talk-cz mailing list
>  talk-cz@openstreetmap.org
>  https://lists.openstreetmap.org/listinfo/talk-cz
>  https://openstreetmap.cz/talkcz
>>>
>>> 
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>>
>> 
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Borne Michelin

[Rpnpif]

Le  8 mai 2019, Gwenaël Jouvin via Talk-fr a écrit :

> Nous en avons récemment parlé pour les boîtes aux lettres, j’ai repris ton 
> idée ;-)
> 
> Pour moi, date de fabrication et date de mise en service sont différentes, 
> même si ça peut paraître être un faible écart 60 ans après…
> Dans ce genre de cas, la date de mise en service est inconnue.


Par contre, name=Ancienne borne Michelin ne convient pas car c'est
plutôt une description que le nom.
En fait, en général, il n'y a pas de nom sauf pour les vieux panneaux
traffic_sign=city_limit qui ont celui de l'agglomération.

-- 
Alain Rpnpif

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Modif majeure merdique

[Rpnpif]

Bonjour,

Le  8 mai 2019, Francois Gouget a écrit :

> On Wed, 8 May 2019, Vincent Bergeot wrote:
> [...]
> > il a arpenté le monsieur : http://overpass-turbo.eu/s/IO0 (  
> [...]
> 
> Au vu du résultat de la requête Overpass je me suis demandé si ce 
> n'était pas simplement tous les "lieux-dits" FANTOIR.
> 
> Ces derniers ne sont pour la plupart pas des lieux-dits mais des noms de 
> parcelle du cadastre qui ne sont, dans mon experience, pas réellement 
> usités, même par ceux qui habitent sur cette parcelle où y ont un champ. 
> Du coup pour la plupart le bon status dans FANTOIR semble être : "Nom 
> introuvable sur le terrain".
> 
> Mais en regardant Saint-Martin-le-Noeud, il y a 55 "lieux-dits" FANTOIR 
> et je n'ai pas l'impression qu'il y en ait autant dans les résultats 
> Overpass. De plus les lieux-dits ajoutés ne correspondent pas tous aux 
> noms FANTOIR. Par exemple rien ne correspond à "Le Pré des Oisons", 
> "Talma" ou "Les Osiers", ce qui suppose une autre source.
> 
> Par contre on trouve aussi des correspondances comme le "Lieu-dit le 
> Bois de la Grange", ce qui est logique, mais bien sûr impossible pour 
> FANTOIR de s'y retrouver en raison du mauvais type de point et du 
> préfixe "Lieu-dit".
> 
> https://cadastre.openstreetmap.fr/fantoir/#insee=60586=4
> 
> 
> [...]
> > on part plutôt sur du place=locality ->
> > https://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality  
> 
> Ou du place=hamlet s'il y a des maisons proches.
> 
> 

Ou du place=isolated_dwelling.

Par ailleurs, ce n'est pas parce qu'il n'y a pas de panneau sur le
lieu et que ces noms sont « introuvables sur le terrain », même pour une
simple parcelle, qu'ils ne sont pas utilisés.

Je connais de très nombreux cas ainsi où ces noms permettent de repérer
des parcelles ou lieux-dits inhabités (locality) utiles pour les PLU,
actes notariaux, ou simplement pour des riverains, propriétaires,
exploitants qui les utilisent oralement. Même si les plus jeunes
d'entre eux les oublient parfois ou ne les connaissent pas.

-- 
Alain Rpnpif

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Rotatorie aperte

[Tatti Barletta]

Il giorno ven, 10/05/2019 alle 10.23 +0200, Lorenzo Beltrami ha
scritto:
> Nel caso specifico sono sbagliati i dati su OSM. La rotonda non aveva
> il
> tag "junction=roundabout" (ora l'ho inserito, bisogna aspettare che
> il
> router si aggiorni).

Grazie mille, non avevo proprio notato il problema! :o


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Tatti Barletta]

Grazie per l'esaustiva risposta, me la appunto a lato dello schermo :D


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Tatti Barletta]

Il giorno ven, 10/05/2019 alle 10.18 +0200, Simone Saviolo ha scritto:
> Ma non per i multipoligoni. No highway nei multipoligoni.

La relazione è di tipo boundary, errore mio scusate.


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Lorenzo Beltrami]

Sono d'accordo con Damjan in quanto le rotonde spezzate servono anche per
le route degli autobous (nel wiki è proprio indicato di spezzarle).

Nel caso specifico sono sbagliati i dati su OSM. La rotonda non aveva il
tag "junction=roundabout" (ora l'ho inserito, bisogna aspettare che il
router si aggiorni).
Direi che i router già gestiscono la cosa infatti la rotonda successiva,
spezzata anch'essa, viene gestita correttamente.

Lorenzo

Il giorno ven 10 mag 2019 alle ore 10:10 Damjan Gerl  ha
scritto:

> Direi che è un problema di router, che deve capire (dal tag) che si trova
> in una rotatoria ed agire di conseguenza. Perciò io lascerei cosi,
> rotatoria spezzata ed in relazione solo il pezzo di rotatoria che serve.
>
> Damjan
>
>
> -- Original Header ---
>
> From  : "Tatti Barletta" tatti.barle...@gmx.it
> To  : talk-it@openstreetmap.org
> Cc  :
> Date  : Fri, 10 May 2019 09:55:15 +0200
> Subject : [Talk-it] Rotatorie aperte
>
> > Buongiorno a tutti,
> > controllando le modifiche recenti nella mia città, ho notato che sono
> > presenti diverse rotatorie "aperte", ossia formate da più segmenti
> > invece che da un percorso unico. Prendendo come esempio la relazione
> > 2573011 [1], è possibile notare questa situazione in più punti. Ciò
> > rompe il comportamento di alcuni servizi di routing [2], i quali non
> > sono più in grado di stabilire che ci si trova all'interno di una
> > rotatoria e fornire di conseguenza indicazioni accurate.
> >
> > Sono abbastanza sicuro che i percorsi che compongono queste rotatorie
> > vadano collegati, ovviamente prestando attenzione a non distruggere le
> > relazioni che li comprendono. Mi vengono in mente due possibili
> > soluzioni:
> >
> >1. aggiungere alla relazione l'intera rotatoria;
> >2. aggiungere alla relazione un nuovo segmento sovrapposto (stessi
> >   nodi) al tratto di rotatoria interessato.
> >
> > L'idea 1. creerebbe un multipoligono [1] con un bordo outer non lineare
> > e non so se sia una cosa accettabile. L'idea 2. creerebbe segmenti
> > sovrapposti e non so se neppure questo sia accettabile (ricordo che
> > lessi sulla wiki qualcosa in merito alle sovrapposizioni parecchi anni
> > fa, ma non riesco a ritrovare la pagina).
> >
> > Ho bisogno di un vostro consiglio :D
> >
> >
> > [1] https://www.openstreetmap.org/relation/2573011
> > [2] https://imgur.com/a/MUjGM0m
> >
> >
> > ___
> > Talk-it mailing list
> > Talk-it@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-it
> >
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Simone Saviolo]

Il giorno ven 10 mag 2019 alle ore 10:10 Damjan Gerl  ha
scritto:

> Direi che è un problema di router, che deve capire (dal tag) che si trova
> in una rotatoria ed agire di conseguenza. Perciò io lascerei cosi,
> rotatoria spezzata ed in relazione solo il pezzo di rotatoria che serve.
>

+1

Ma non per i multipoligoni. No highway nei multipoligoni.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Simone Saviolo]

Il giorno ven 10 mag 2019 alle ore 09:57 Tatti Barletta <
tatti.barle...@gmx.it> ha scritto:

> Buongiorno a tutti,
> controllando le modifiche recenti nella mia città, ho notato che sono
> presenti diverse rotatorie "aperte", ossia formate da più segmenti
> invece che da un percorso unico. Prendendo come esempio la relazione
> 2573011 [1], è possibile notare questa situazione in più punti. Ciò
> rompe il comportamento di alcuni servizi di routing [2], i quali non
> sono più in grado di stabilire che ci si trova all'interno di una
> rotatoria e fornire di conseguenza indicazioni accurate.
>
> Sono abbastanza sicuro che i percorsi che compongono queste rotatorie
> vadano collegati, ovviamente prestando attenzione a non distruggere le
> relazioni che li comprendono. Mi vengono in mente due possibili
> soluzioni:
>
>1. aggiungere alla relazione l'intera rotatoria;
>2. aggiungere alla relazione un nuovo segmento sovrapposto (stessi
>   nodi) al tratto di rotatoria interessato.
>
> L'idea 1. creerebbe un multipoligono [1] con un bordo outer non lineare
> e non so se sia una cosa accettabile. L'idea 2. creerebbe segmenti
> sovrapposti e non so se neppure questo sia accettabile (ricordo che
> lessi sulla wiki qualcosa in merito alle sovrapposizioni parecchi anni
> fa, ma non riesco a ritrovare la pagina).
>
> Ho bisogno di un vostro consiglio :D
>

Ho incontrato anch'io il problema che descrivi.

Se si tratta di una relazione route (ad esempio una linea del bus),
evidentemente la cosa più corretta sarebbe spezzare la rotonda: il bus
entra da una parte ed esce due uscite dopo, ad esempio, e quindi includere
tutta la rotonda sarebbe sbagliato. Quanto sbagliato? Beh, da un certo
punto di vista potrebbe essere accettabile: un consumatore potrebbe
- ignorare la cosa, perché ad esempio sta disegnando la rotta, e allora
dice soltanto "la rotta passa da questa rotonda"
- calcolare correttamente: il bus deve andare da Via Tizio a Corso Caio,
che sono congiunti da una rotonda? Evidentemente non percorrerà tutta la
rotonda, ma solo il tratto tra Via Tizio e Corso Caio
Cioè che sarebbe sicuramente male sarebbe sovrapporre una seconda way
soltanto per la route.

Se si tratta di un multipoligono, invece, la cosa cambia. Includere tutta
la rotonda sarebbe sbagliato: contorno non aciclico, difficoltà a
distinguere il dentor e il fuori, etc. Spezzarla sarebbe più giusto: nel
multipoligono va solo il pezzo che serve. Ma in realtà sono sbagliate
entrambe: qual è il multipoligono che deve necessariamente essere definito
dalla way di una strada? Anzi, qual è l'area semplice che deve essere
definita dalla way di una strada? Non mi viene in mente nessun caso d'uso
in cui un'area sia delimitata dal *centro* di una strada. In quel caso, ti
dico: sgancia il tuo multipoligono dalla rotonda, ma sgancialo anche da
qualsiasi altra strada, e disegna una nuova way con il vero contorno
dell'area che ti interessa.

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rotatorie aperte

[Damjan Gerl]

Direi che è un problema di router, che deve capire (dal tag) che si trova in 
una rotatoria ed agire di conseguenza. Perciò io lascerei cosi, rotatoria 
spezzata ed in relazione solo il pezzo di rotatoria che serve.

Damjan


-- Original Header ---

From  : "Tatti Barletta" tatti.barle...@gmx.it
To  : talk-it@openstreetmap.org
Cc  : 
Date  : Fri, 10 May 2019 09:55:15 +0200
Subject : [Talk-it] Rotatorie aperte

> Buongiorno a tutti,
> controllando le modifiche recenti nella mia città, ho notato che sono
> presenti diverse rotatorie "aperte", ossia formate da più segmenti
> invece che da un percorso unico. Prendendo come esempio la relazione
> 2573011 [1], è possibile notare questa situazione in più punti. Ciò
> rompe il comportamento di alcuni servizi di routing [2], i quali non
> sono più in grado di stabilire che ci si trova all'interno di una
> rotatoria e fornire di conseguenza indicazioni accurate.
> 
> Sono abbastanza sicuro che i percorsi che compongono queste rotatorie
> vadano collegati, ovviamente prestando attenzione a non distruggere le
> relazioni che li comprendono. Mi vengono in mente due possibili
> soluzioni:
> 
>1. aggiungere alla relazione l'intera rotatoria;
>2. aggiungere alla relazione un nuovo segmento sovrapposto (stessi
>   nodi) al tratto di rotatoria interessato.
> 
> L'idea 1. creerebbe un multipoligono [1] con un bordo outer non lineare
> e non so se sia una cosa accettabile. L'idea 2. creerebbe segmenti
> sovrapposti e non so se neppure questo sia accettabile (ricordo che
> lessi sulla wiki qualcosa in merito alle sovrapposizioni parecchi anni
> fa, ma non riesco a ritrovare la pagina).
> 
> Ho bisogno di un vostro consiglio :D
> 
> 
> [1] https://www.openstreetmap.org/relation/2573011
> [2] https://imgur.com/a/MUjGM0m
> 
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] iD führt nosquare=yes für nicht rechtwinklige Gebäude ein (WAS: Besorgt über den iD-Editor)

[Martin Koppenhoefer]

sent from a phone

> On 9. May 2019, at 22:55, Michael Reichert  wrote:
> 
> Wenn ihr eine Meinung zu der Sache habt, egal welche, steht es euch
> natürlich frei, euch auf GitHub, auf dieser Mailingliste oder auf der
> Mailingliste Talk zu äußern.


Danke für Deinen Einsatz, ich sehe das Monieren von nicht rechtwinkligen 
Gebäuden auch als Problem und von daher auch den tag als kritisch.

(im Gegensatz übrigens zu noname und dem neuen nohousenumber)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-it] Rotatorie aperte

[Tatti Barletta]

Buongiorno a tutti,
controllando le modifiche recenti nella mia città, ho notato che sono
presenti diverse rotatorie "aperte", ossia formate da più segmenti
invece che da un percorso unico. Prendendo come esempio la relazione
2573011 [1], è possibile notare questa situazione in più punti. Ciò
rompe il comportamento di alcuni servizi di routing [2], i quali non
sono più in grado di stabilire che ci si trova all'interno di una
rotatoria e fornire di conseguenza indicazioni accurate.

Sono abbastanza sicuro che i percorsi che compongono queste rotatorie
vadano collegati, ovviamente prestando attenzione a non distruggere le
relazioni che li comprendono. Mi vengono in mente due possibili
soluzioni:

   1. aggiungere alla relazione l'intera rotatoria;
   2. aggiungere alla relazione un nuovo segmento sovrapposto (stessi
  nodi) al tratto di rotatoria interessato.

L'idea 1. creerebbe un multipoligono [1] con un bordo outer non lineare
e non so se sia una cosa accettabile. L'idea 2. creerebbe segmenti
sovrapposti e non so se neppure questo sia accettabile (ricordo che
lessi sulla wiki qualcosa in merito alle sovrapposizioni parecchi anni
fa, ma non riesco a ritrovare la pagina).

Ho bisogno di un vostro consiglio :D


[1] https://www.openstreetmap.org/relation/2573011
[2] https://imgur.com/a/MUjGM0m


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Lester]

On 09/05/2019 23:21, Michael Reichert wrote:

JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
   objects they did not touch.

- If users follow suggestions how to fix blindly (we cannot expect an
   unexperienced iD user to have the same knowledge as the average JOSM
   user), they are used as living bots running validation rules on
   randomly selected areas of the map. One might call this a hidden
   automated edit.


Been some time since I put buildings in, but surely the the right way to 
handle ADDING a square building is just to select 'box' and position 2 
diagonal corners? With the logic picking up the adjacent corners of 
another square building? This is a drawing problem rather than something 
that gets tagged to sort out later? A row of houses simply square off an 
existing wall. Editing a block of building drawn as a single block to 
provide individual units needs the right tools rather than some tag 
saying 'this block was not square last time I drew it'?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-cz] Značení turistických trasy s tagem name = [barva] destinace

[Majka]

V tomhle se asi neshodneme. Za mě to patří do description, jak pro editaci, tak 
pro případné zobrazení přes render.

Protože jinak nemám možnost si to zobrazit jen v případě zájmu. Navíc name v 
délce odstavce jen jen a pouze opruz. 

A jaký je rozdíl pro editaci (v JOSM) mezi tím, mít to v name nebo description? 
Podle mě žádný. Zobrazit si to můžu "v mapě" i tak, hledat v tom můžu taky... 

10. května 2019 8:56:40 SELČ, Miroslav Suchy  napsal:
>
>
>Je pravda, že pracovat s relacemi, pokud nemají vyplněná jména je
>šílený opruz. 
>
>
>Takže na mapování pro render (nebo mapovací nástroje) mám už trochu
>volnější názor. 

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Značení turistických trasy s tagem name = [barva] destinace

[Miroslav Suchy]

Dne 10. 05. 19 v 8:11 <0174 napsal(a):
> Abych to shrnul, tento popis podle mého názoru patří jestli někam, tak do 
> description, nejlépe description:cz. Nicméně
> text nenese informace, které by nešly získat z tagů osmc:symbol a 
> destinations, takže mi celkově přijde zbytečný. Chápu,
> že si s tím někdo asi dal dost práce, ale prošlo to někde nějakou diskusí? 
> "source:name" nemá vyplněná ani jedna relace,
> tak nevím, odkud se to bere:
> https://overpass-turbo.eu/s/IO7
> 
> Předem díky za názory.

Čistě formálně - ano, je to jednoznačně špatně a nemá to v name=* co dělat. 
Ovšem...

Je pravda, že pracovat s relacemi, pokud nemají vyplněná jména je šílený opruz. 
Někdy je to na hranici možného a musím
si minimálně po dobu editace dát do name nějaký dočasný text a před uploadem ty 
texty zase odstranit.

Ještě před rokem bych horoval taky za odstranění a formální čistotu. Ale loni 
jsem byl v Africe a na spoustě
highway=track je name "4x4 only" nebo "Twee Spoor Track" (náhon na dvě kola). 
Obojí je také jednoznačně špatně, protože
na kvalitu povrchu máme jiný tag. Než jsem tam jel, tak jsem měl tendeci to 
mazat. Ovšem na místě jsem zjistil, že mít
tuhle informaci viditelnou v renderu je hodně užitečné. Rozhodně to někdy 
zabrání celodennímu se vracení a ztrátě dvou
dní na cestě. Což se někdy rovná dehydrataci a hladovění. To jsem si vyzkoušel 
na vlastní kůži :)

Takže na mapování pro render (nebo mapovací nástroje) mám už trochu volnější 
názor. A raději než *teď* provádět hromadné
mazání, tak bych doporučil upnout sílu k tomu nahlásit RFE na nejpouživanější 
editory (iD a JOSM) aby v dropdown menu
ukazovali name:editor nebo neco podobneho (a projit navrhem na takovy tag) a 
teprve az tohle bude, tak tam presunout
tyhle špatná jména.

Toliko moje dva centy.

Mirek

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-us] Whole-US Garmin Map update - 2019-05-07

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2019-05-07

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2019-05-07/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2019-05-07

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-cz] Body záchrany Lesy ČR

[Majka]

Jsem taky pro revert. 
Snaha pořešit duplicity tam byla dodatečně po tom mailu, v noci jsem viděla dvě 
sady změn, které je mazaly. Takže revert bude trochu náročnější, zvlášť pokud 
tam přistálo něco dalšího. 

Jako úmysl 1*, ale provedení tak 4- 

10. května 2019 8:11:33 SELČ, Tom Ka  napsal:
>Ahoj, data jsou super ale skoro bych v tomhle pripade udelal revert na
>tu sadu zmen at se nedelaji kolize - podle toho, co jsem se koukal, to
>vubec neresi duplicity. Pak bych z te sady zmen udelal seznam pro
>nasledny import jedne jednou a poradne pote, co bude nejak dolozen
>souhlas Lesu CR. Co vy na to?
>
>Bye
>
>čt 9. 5. 2019 v 23:36 odesílatel Majka 
>napsal:
>>
>> Souhlasím se vším uvedeným, jen source se aktuálně doporučuje (na
>import listu) jen na sadě změn, kde je uvedený.
>>
>> To ostatní všechno vyplývá z bodu jedna - každý import je třeba
>projednat tady a minimálně oznámit na import listu. Na 90% se proti
>tomu někdo ozve, tohle bude jednoznačně flagnuto jako nedovolený import
>a rozsahem to nezapadne.
>>
>> 9. května 2019 23:28:05 SELČ, Jan Macura 
>napsal:
>>>
>>> Také zdravím,
>>>
>>> určitě díky za pěkné obohacení OSM a zařízení souhlasu od instituce!
>(btw, nebyl by písemně?)
>>>
>>> Mám ale několik připomínek, které mi kazí radost...
>>>
>>> Kde je souhlas komunity OSM s importem? Jak byly řešeny vzniknuvší
>duplicity v datech? Jak byly vybrány použité tagy? Proč jsou u bodů
>uvedeny souřadnice jako tagy X a Y? Proč mají všechny body "name=Bod
>záchrany - Rescue Point" navzdory všem doporučením o tom, co by mělo
>být obsahem klíče name? Proč není uveden zdroj dat v klíči source? Jaká
>je přesnost dat? Jak budou data udržována aktuální? Atd. ...
>>>
>>> Aspoň, že je vše nahráno v jedné snadno dohledatelné sadě změn!
>>>  H.
>>>
>>> On Thu, 9 May 2019 at 22:53, Spratek  wrote:

 Zdravím,
 se souhlasem Lesů ČR jsem na OSM nahrál kompletní seznam Bodů
>záchrany spravovaných Lesy ČR.
 Celkem jich je 2171.
 Přehledná mapka bodů je zde:

>https://commons.wikimedia.org/wiki/File:Body_z%C3%A1chrany_-_Lesy_%C4%8CR.jpg

 Doufám, že jich bude potřeba co nejmíň.
 Míru zdar.

 ___
 talk-cz mailing list
 talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz
 https://openstreetmap.cz/talkcz
>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>
>___
>talk-cz mailing list
>talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] operateur d'un service postal post_office:type=post_partner

[PanierAvide]

Bonjour Marc,

C'est vrai que la notion d'opérateur n'est pas appropriée pour ce type 
de point relais postal, c'est à mon avis préférable de basculer sur 
brand=La Poste (peut-être pas network car la Poste/relais postaux vend 
aussi des services qui ne sont pas opérés par La Poste ?). Idéalement si 
on pouvait indiquer comme opérateur le nom de la société qui gère le 
point relais (société du resto/magasin/...), mais là ça va être 
compliqué :-)


Cordialement,

Adrien P.

Le 10/05/2019 à 01:43, marc marc a écrit :

Bonjour,

Un service postal post_office:type=post_partner
ne devrait-il se voir supprimer le operator="La Poste" ?
il y en a actuellement 827
https://overpass-turbo.eu/s/IRp

Je ne demande aussi si ce nettoyage nécessiterait brand/network="La
Poste" pour faire la différence avec la collecte et distribution faite
par d'autres firmes privées
Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Značení turistických trasy s tagem name = [barva] destinace

[Tom Ka]

Ahoj, rekl bych, ze je to dano historicky, nekdo to nekdy pouzival a
ostatni to pak (v nekterych pripadech) kopiruji. Mozna by se dalo
pohledat historie techto relaci a najit spolecne lidi, ale asi to je
zbytecna prace. Jedine male pozitivum je, ze je to pekne videt v
seznamu relaci (napr. v JOSM), ale to rozhodne neni duvod pro to, to
takto delat. Za mne tedy souhlas, ze pokud to neni nazev (coz ale bude
potreba asi zkontrolovat +- rucne, max podle toho [ na zacatku), tak
to tam nepatri. Jestli to dat do description (description:cz je podle
mne zbytecne), je otazka, mozna spise do note, kdyz uz se to bude
uklizet.

Bye

pá 10. 5. 2019 v 8:12 odesílatel <0174  napsal:
>
> Ahoj,
> poslední dobou vidím poměrně často, že turistická trasa má v tagu "name" text 
> ve formátu [barva] začátek - mezicíl1 mezicíl 2 ... konec. Snažil jsem se 
> najít, co k tomu autora/y vede, ale nenašel jsem nic. Rád bych tedy nadhodil 
> k diskusi, co s tím (jestli něco). Těchto relací je v ČR celkem 2295, takže 
> se rozhodně nejedná o ojedinělý případ.
> https://overpass-turbo.eu/s/IO6
>
> Na naší Wiki se doslova píše (zvýraznění původní):
> ---
> Příklad otagované relace:
> [...]
> name=Blanická cesta (pouze pokud to je oficiální název)
> ---
> https://wiki.openstreetmap.org/wiki/Cs:WikiProjekt_%C4%8Cesko/Edita%C4%8Dn%C3%AD_standardy_a_konvence#Turistick.C3.A9_zna.C4.8Den.C3.AD
>
> V seznamu tras KČT jsem žádné takové názvy taky nenašel:
> http://trasy.kct.cz/
>
> Na mailing-listu jsem také nic nenašel (ale samozřejmě jsem mohl hledat 
> špatně).
>
> Na OSM Wiki se píše v popisu tagu name:
> The common default name.
> https://wiki.openstreetmap.org/wiki/Key:name
> Nemyslím si, že by tento formát kdekoliv někdo používal, natož aby byl 
> "common" či "default".
>
> Proč se mi to nelíbí:
> - Přijde mi to jako mapování pro renderer. Jasně, taky se mi špatně orientuje 
> v seznamu relací v JOSM, ale to podle mě není důvod dávat do jména věci, 
> které jménem nejsou.
> - Použití českých písmen pro barvu značky.
> - Pro prakticky založené konkrétní případ, kde mi to vadí - když se mi na mém 
> eTrexu 30 na displeji 176x200 px objeví jméno trasy "[M] Nepomuk - Blovice - 
> Vlčtejn - Nebílovský Borek" (dnešní případ), tak je to značně nepřehledné.
>
> Abych to shrnul, tento popis podle mého názoru patří jestli někam, tak do 
> description, nejlépe description:cz. Nicméně text nenese informace, které by 
> nešly získat z tagů osmc:symbol a destinations, takže mi celkově přijde 
> zbytečný. Chápu, že si s tím někdo asi dal dost práce, ale prošlo to někde 
> nějakou diskusí? "source:name" nemá vyplněná ani jedna relace, tak nevím, 
> odkud se to bere:
> https://overpass-turbo.eu/s/IO7
>
> Předem díky za názory.
>
> Vojta aka <0174
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Fwd: tak už je to v provozu!

[Petr Schönmann]

Zrovna včera jsem nějaké kontejnery do mapy dával a přidával jsem je přes
ortofoto IPR. K mému údivu bylo ze mapy.cz jsou v Praze stejné jako jako
ortofoto od IPRu, byť ty od IPR jsou trošku rozmazanější
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Body záchrany Lesy ČR

[Tom Ka]

Ahoj, data jsou super ale skoro bych v tomhle pripade udelal revert na
tu sadu zmen at se nedelaji kolize - podle toho, co jsem se koukal, to
vubec neresi duplicity. Pak bych z te sady zmen udelal seznam pro
nasledny import jedne jednou a poradne pote, co bude nejak dolozen
souhlas Lesu CR. Co vy na to?

Bye

čt 9. 5. 2019 v 23:36 odesílatel Majka  napsal:
>
> Souhlasím se vším uvedeným, jen source se aktuálně doporučuje (na import 
> listu) jen na sadě změn, kde je uvedený.
>
> To ostatní všechno vyplývá z bodu jedna - každý import je třeba projednat 
> tady a minimálně oznámit na import listu. Na 90% se proti tomu někdo ozve, 
> tohle bude jednoznačně flagnuto jako nedovolený import a rozsahem to 
> nezapadne.
>
> 9. května 2019 23:28:05 SELČ, Jan Macura  napsal:
>>
>> Také zdravím,
>>
>> určitě díky za pěkné obohacení OSM a zařízení souhlasu od instituce! (btw, 
>> nebyl by písemně?)
>>
>> Mám ale několik připomínek, které mi kazí radost...
>>
>> Kde je souhlas komunity OSM s importem? Jak byly řešeny vzniknuvší duplicity 
>> v datech? Jak byly vybrány použité tagy? Proč jsou u bodů uvedeny souřadnice 
>> jako tagy X a Y? Proč mají všechny body "name=Bod záchrany - Rescue Point" 
>> navzdory všem doporučením o tom, co by mělo být obsahem klíče name? Proč 
>> není uveden zdroj dat v klíči source? Jaká je přesnost dat? Jak budou data 
>> udržována aktuální? Atd. ...
>>
>> Aspoň, že je vše nahráno v jedné snadno dohledatelné sadě změn!
>>  H.
>>
>> On Thu, 9 May 2019 at 22:53, Spratek  wrote:
>>>
>>> Zdravím,
>>> se souhlasem Lesů ČR jsem na OSM nahrál kompletní seznam Bodů záchrany 
>>> spravovaných Lesy ČR.
>>> Celkem jich je 2171.
>>> Přehledná mapka bodů je zde:
>>> https://commons.wikimedia.org/wiki/File:Body_z%C3%A1chrany_-_Lesy_%C4%8CR.jpg
>>>
>>> Doufám, že jich bude potřeba co nejmíň.
>>> Míru zdar.
>>>
>>> ___
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Značení turistických trasy s tagem name = [barva] destinace

[<0174]

Ahoj,
poslední dobou vidím poměrně často, že turistická trasa má v tagu "name"
text ve formátu *[barva] začátek - mezicíl1 mezicíl 2 ... konec*. Snažil
jsem se najít, co k tomu autora/y vede, ale nenašel jsem nic. Rád bych tedy
nadhodil k diskusi, co s tím (jestli něco). Těchto relací je v ČR celkem
2295, takže se rozhodně nejedná o ojedinělý případ.
https://overpass-turbo.eu/s/IO6

Na naší Wiki se doslova píše (zvýraznění původní):
---

*Příklad otagované relace: *[...]
name=Blanická cesta *(pouze pokud to je oficiální název)*
---
https://wiki.openstreetmap.org/wiki/Cs:WikiProjekt_%C4%8Cesko/Edita%C4%8Dn%C3%AD_standardy_a_konvence#Turistick.C3.A9_zna.C4.8Den.C3.AD

V seznamu tras KČT jsem žádné takové názvy taky nenašel:
http://trasy.kct.cz/

Na mailing-listu jsem také nic nenašel (ale samozřejmě jsem mohl hledat
špatně).

Na OSM Wiki se píše v popisu tagu name:
*The common default name.*
https://wiki.openstreetmap.org/wiki/Key:name
Nemyslím si, že by tento formát kdekoliv někdo používal, natož aby byl
"common" či "default".

Proč se mi to nelíbí:
- Přijde mi to jako mapování pro renderer. Jasně, taky se mi špatně
orientuje v seznamu relací v JOSM, ale to podle mě není důvod dávat do
jména věci, které jménem nejsou.
- Použití českých písmen pro barvu značky.
- Pro prakticky založené konkrétní případ, kde mi to vadí - když se mi na
mém eTrexu 30 na displeji 176x200 px objeví jméno trasy "[M] Nepomuk -
Blovice - Vlčtejn - Nebílovský Borek" (dnešní případ), tak je to značně
nepřehledné.

Abych to shrnul, tento popis podle mého názoru patří jestli někam, tak do
description, nejlépe description:cz. Nicméně text nenese informace, které
by nešly získat z tagů osmc:symbol a destinations, takže mi celkově přijde
zbytečný. Chápu, že si s tím někdo asi dal dost práce, ale prošlo to někde
nějakou diskusí? "source:name" nemá vyplněná ani jedna relace, tak nevím,
odkud se to bere:
https://overpass-turbo.eu/s/IO7

Předem díky za názory.

Vojta aka <0174
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz