[Talk-it] Terminiamo la traduzione del Tasking Manager 3

[Alessandro P. via Talk-it]

Buongiorno,
iniziamo con la buona notizia: il buon Paolo "Geofrizz" potrebbe 
riuscire a mettere in piedi in tempi ragionevoli il Tasking Manager 
aggiornato alla versione 3. Ha avuto accesso al vecchio server 
esportando il DB e forse si riuscirà anche a migrare sul nuovo senza 
perdere lo storico dei Task.


E ora veniamo con la richiesta: ieri ho notato che la traduzione 
italiana del TM3 è ferma a dove l'avevamo condotta l'anno scorso col 
pugno di volonterosi che lavorò a LearnOSM e altro. Ieri ho tradotto una 
ottantina di frasi, ora ne rimangono 93, più un pò di review su quelle 
già tradotte.


Chi vuole dare una mano trova la traduzione qui:
https://www.transifex.com/hotosm/tasking-manager-3/

Saluti
  Alessandro Ale_Zena_IT

P.S.: con Paolo stavamo anche pensando ad una istanza di uMap con un 
occhio alle scuole, aggiungendo un pò di icone e mappe mute dell'Italia 
e delle regioni.


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

Re: [Talk-it-trentino] mappa cartacea con dati OSM

[Luca Delucchi]

On Fri, 25 Jan 2019 at 08:02, Maurizio Napolitano 
wrote:

> È un po' borderline ma possibile
> Unico dubbio è se prende uno "strato" di dati (esempio le fontanelle
> dell'acqua) oppure se mescola e/o corregge
> In questo ultimo caso credo che debba rilasciare le modifiche
>

concordo, se i layer OSM utilizzati non sono mischiati con dati suoi non
deve rilasciare le modifiche

-- 
ciao
Luca

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

Re: [OSM-talk-fr] Cimetière militaire

[Florian LAINEZ]

Hello,
Merci pour vos retours.

Dans l'idée de préciser un cemerery=sector on peut en effet utiliser
sector=military.
Cela me parait compatible et cumulable avec religion=* si besoin, qui est
le tag que j'utiliserai pour un carré musulman/juif ...

Le jeu. 24 janv. 2019 à 21:47, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> a écrit :

> Voir cette discussion récente sur les carrés confessionnels:
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-December/091336.html
> .
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [Talk-it-trentino] mappa cartacea con dati OSM

[Maurizio Napolitano]

È un po' borderline ma possibile
Unico dubbio è se prende uno "strato" di dati (esempio le fontanelle
dell'acqua) oppure se mescola e/o corregge
In questo ultimo caso credo che debba rilasciare le modifiche
Io chiederei di scrivere tutte le fonti e cosa prendono

In ogni caso una email al LWG di OSM potrebbe risolvere i dubbi

Il giorno Gio 24 Gen 2019, 21:37 Dario Zontini Gmail <
dario.zont...@gmail.com> ha scritto:

> Una nota ditta per cartine escursionistiche mi ha contattato per
> chiedere collaborazione nel controllare la correttezza dei dati dei
> sentieri SAT della mia sezione. Premetto che il risultato è molto bello,
> e nella mappa ci sono sia dati OSM e dati probabilmente proprietari. Mi
> hanno assicurato che verrà indicato che sono stati usati dati OSM con la
> corretta citazione, ma mi chiedo: è  corretto fare questo? il mio dubbio
> è che una volta stampata su carta non è possibile distinguere i dati
> OSM  da quelli proprietari.
>
> --
>
>
> Dario Zontini
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [Talk-it-trentino] mappa cartacea con dati OSM

[Dario Zontini]

Non ha importanza il nome della ditta.

Dario Zontini

Il giorno gio 24 gen 2019, 21:41 Michele Malfatti <
michele.malfa...@gmail.com> ha scritto:

> 4land o kompass?
>
> Sent from my iPhone
>
> > On 24 Jan 2019, at 21:37, Dario Zontini Gmail 
> wrote:
> >
> > Una nota ditta per cartine escursionistiche mi ha contattato per
> chiedere collaborazione nel controllare la correttezza dei dati dei
> sentieri SAT della mia sezione. Premetto che il risultato è molto bello, e
> nella mappa ci sono sia dati OSM e dati probabilmente proprietari. Mi hanno
> assicurato che verrà indicato che sono stati usati dati OSM con la corretta
> citazione, ma mi chiedo: è  corretto fare questo? il mio dubbio è che una
> volta stampata su carta non è possibile distinguere i dati OSM  da quelli
> proprietari.
> >
> > --
> >
> >
> > Dario Zontini
> >
> >
> > ---
> > Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> > https://www.avast.com/antivirus
> >
> >
> > ___
> > Talk-it-trentino mailing list
> > Talk-it-trentino@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [talk-au] Announcing: OpenStreetCam competition

[Martijn van Exel]

Hi all!

Let me give you a status update on the OpenStreetCam competition. We have about 
a week to go before the $100 prize and two $25 prizes will be awarded to the 
most prolific OpenStreetCammers. If you have the app, you can pull up the 
leaderboard and get some idea of where you stand.

The community had collected 144,000 images in Australia before December 1, when 
the competition started. Since then, you collected 191,000 more, comfortably 
doubling coverage in Australia. Wonderful! The last few days saw a particularly 
nice trend upwards.

Also, a word on Waylens dashboard cameras. Telenav had customized cameras made 
that capture and upload OpenStreetCam imagery automatically. OSM US has around 
20 that they lend to their members. A blog post[1] explains in a bit more 
detail what these cameras are. We have some to give out. I would prefer to give 
them to one or more local communities who want to make an effort to capture 
their entire city or area. If you’re interested, please get in touch with me 
off-list.

Happy mapping,
Martijn

[1] https://www.openstreetmap.us/2018/05/camera-lending-program/

> On Jan 18, 2019, at 2:26 PM, Martijn van Exel  wrote:
> 
> Hi all, 
> 
> I am not sure if user robbie-blogs is reading on this list -- if you are, 
> please get in touch to get your gift card.
> 
> For all others, the competition is still ongoing and you have until Jan 31 to 
> make your way into the top 3 contributors over the months of December 2018 
> and January 2019 and win a $25 or $100 gift card.
> 
> Some stats so far: we started at 126 752 images in Australia on Dec 1, now we 
> are at 330 648 covering 8882 km of which 6293 unique.
> 
> Happy mapping / capturing :)
> --
>   Martijn van Exel
>   m...@rtijn.org 
> 
> 
> On Tue, Jan 8, 2019, at 16:40, Martijn van Exel wrote:
>> Hi all,
>> 
>> We have the results for the most prolific OpenStreetCam contributors for 
>> Australia for the period Dec 1 - Dec 24:
>> 
>> 
>> #1 ---> robbie-bloggs with 127971 points
>> #2 ---> steve91 with 65470 points
>> 
>> 
>> Congratulations to you both, you have just won yourselves an $25 Amazon gift 
>> card! Please get in touch with me so I can arrange (virtual) delivery.
>> 
>> It's not over yet though. This was just the holiday mid point of the 
>> competition. At the end of January there will be three more prizes ($100 / 
>> $25 / $25) for the overall top contributors for the months of December and 
>> January.
>> 
>> If you haven't started capturing yet, no worries. New, not yet covered roads 
>> get you 10x points. That adds up pretty quickly. For example, this 20km trip 
>> is worth more than 6000 points: 
>> https://openstreetcam.org/details/1318295/0/track-info 
>>  
>> 
>> Best,
>> --
>>   Martijn van Exel
>>   m...@rtijn.org
>> 
>> 
>> 
>> On Wed, Dec 12, 2018, at 12:33, Martijn van Exel wrote:
>>> Folks,
>>> 
>>> We added an additional holiday prize for the 2 mappers who collect the most 
>>> imagery before Christmas.
>>> Details added on the competition page! You need 25k points minimum to be 
>>> eligible for this prize, but since coverage is very low in Australia,  you 
>>> collect points very quickly.
>>> 
>>> Let me know if you have any questions. Happy mapping / capturing,
>>> --
>>>   Martijn van Exel
>>>   m...@rtijn.org
>>> 
>>> 
>>> 
>>> On Fri, Dec 7, 2018, at 11:53, Martijn van Exel wrote:
 Hi folks, 
 
 We (Telenav map team) are holding an OpenStreetCam image capture 
 competition. In case you're not familiar, OpenStreetCam is an open source 
 / open data street level imagery collection platform for OSM. It is widely 
 used to help improve OSM (through iD and JOSM) but there is not a lot of 
 coverage in Australia yet. So with this competition we’re hoping to start 
 to change that. 
 
 More details here: 
 https://github.com/openstreetcam/competitions/wiki/Australia-Competition-Dec-2018
  
 
  
 
 The TL;DR is: collect as many OSC images as you can between now and Jan 
 31, the top 3 contributors get $100 / $25 Amazon gift cards!
 
 Happy mapping / capturing!
 Martijn
 
 PS in case you’re in NZ, we have a separate competition staring there as 
 well, 
 https://github.com/openstreetcam/competitions/wiki/New-Zealand-Competition-Dec-2018
  
 
  
 ___
 Talk-au mailing list
 Talk-au@openstreetmap.org 
 https://lists.openstreetmap.org/listinfo/talk-au 
 
>>> 
>>> ___
>>> Talk-au mailing list

Re: [talk-au] Our work in last two weeks

[Martijn van Exel]

It sounds like one of those things where opinions are going to vary. Personally 
I would split them, but I don’t think it’s a big deal to do it one way or the 
other, and it doesn’t affect the map either way.

Mapping to make some random QA tool happy doesn’t sound tenable to me. Horea 
(my colleague) shared the OSMCha links mainly because that tool makes it easy 
to show all changesets of a group of mappers in one place. I think it’s a bit 
too opinionated when it comes to identifying ‘errors’. But hey, it’s open 
source software..:)

I’m happy that our work is being scrutinized. Please keep watching our work, we 
need your feedback to make sure we’re doing everything according to local best 
practices.

Martijn

> On Jan 23, 2019, at 2:43 PM, Mark Pulley  wrote:
> 
> I generally split these ways. A couple of reasons:
> 
> 1. Traffic is generally not meant to make U-turns here. Occasionally there is 
> an explicit no-U-turn sign, but most of the time there is a double white line 
> extending from the end of the median strip preventing turning.
> 
> 2. If a route relation uses the road, then it is required to split the road, 
> as traffic following the relation doesn’t do a U-turn. As an example, have a 
> look at https://www.openstreetmap.org/relation/1284045 
>  - ways 
> https://www.openstreetmap.org/way/175260353 
>  and 
> https://www.openstreetmap.org/way/175260354 
>  are the respective forward 
> members for each direction of travel. (Probably easier to see in the relation 
> editor in JOSM) 
> 
> Mark P.
> 
>> On 22 Jan 2019, at 8:23 am, Nemanja Bračko > > wrote:
>> 
>> @Warin,
>> 
>> I personally do not see why is it wrong if you split? It is just two 
>> segments merged in one node. Geometry and data are exactly the same just it 
>> is represented as two, instead of one line.
>> 
>> If we go deeper in this issue, it is actually wrong, because you have 
>> marked/mapped 2 physical segments with just one line. Angle is not natural 
>> for any road. However, it doesn't make any difference in routing so it is 
>> acceptable to be mapped as one line in cases like this.
>> 
>> Thanks,
>> Nemanja
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

[OSM-talk-ie] Belfast meetup

[Tadeusz Cantwell]

We are delighted to announce, as part of our mission to bring OSM to the
whole island, we will be having a mapping session in the QGIS department of
Queens University Belfast. The event will happen on the 16th of Feb from 11
am to 3 pm. Just two hours on the motorway from Dublin! Hope to see some of
you there.

Tadeusz Cantwell
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] il gatto che si morde la coda

[Sergio Manzi]

Claudio, se capisco bene il tuo problema, penso che la risposta ai tuoi dubbi 
sia qui: https://wiki.openstreetmap.org/wiki/Key:parking:lane

In soldoni si tratta di mappare i parcheggi a bordo strada non come entità a se 
stanti, ma come attributi della strada.

Ciao,

Sergio


On 2019-01-24 21:41, claudio62PG wrote:
> Salve ho un problema curioso
> Uso osmose per controllare quello che faccio e mi trovo in questa situazione
> Come mappare i parcheggi bordo strada?
> Se li mappo separati dalla strada osmose 
> mi da errore 
> Via di accesso al parcheggio mancante
>
> se ho un lato in comune mi dice che ho una sovapposizione
> che fare
> Ciao
> Claudio
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Cimetière militaire

[OSMDoudou]

Voir cette discussion récente sur les carrés confessionnels: 
https://lists.openstreetmap.org/pipermail/talk-fr/2018-December/091336.html.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it-trentino] mappa cartacea con dati OSM

[Michele Malfatti]

4land o kompass? 

Sent from my iPhone

> On 24 Jan 2019, at 21:37, Dario Zontini Gmail  wrote:
> 
> Una nota ditta per cartine escursionistiche mi ha contattato per chiedere 
> collaborazione nel controllare la correttezza dei dati dei sentieri SAT della 
> mia sezione. Premetto che il risultato è molto bello, e nella mappa ci sono 
> sia dati OSM e dati probabilmente proprietari. Mi hanno assicurato che verrà 
> indicato che sono stati usati dati OSM con la corretta citazione, ma mi 
> chiedo: è  corretto fare questo? il mio dubbio è che una volta stampata su 
> carta non è possibile distinguere i dati OSM  da quelli proprietari.
> 
> -- 
> 
> 
> Dario Zontini
> 
> 
> ---
> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
> https://www.avast.com/antivirus
> 
> 
> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino

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

[Talk-it] il gatto che si morde la coda

[claudio62PG]

Salve ho un problema curioso
Uso osmose per controllare quello che faccio e mi trovo in questa situazione
Come mappare i parcheggi bordo strada?
Se li mappo separati dalla strada osmose 
mi da errore 
Via di accesso al parcheggio mancante

se ho un lato in comune mi dice che ho una sovapposizione
che fare
Ciao
Claudio




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-it-trentino] mappa cartacea con dati OSM

[Dario Zontini Gmail]

Una nota ditta per cartine escursionistiche mi ha contattato per 
chiedere collaborazione nel controllare la correttezza dei dati dei 
sentieri SAT della mia sezione. Premetto che il risultato è molto bello, 
e nella mappa ci sono sia dati OSM e dati probabilmente proprietari. Mi 
hanno assicurato che verrà indicato che sono stati usati dati OSM con la 
corretta citazione, ma mi chiedo: è  corretto fare questo? il mio dubbio 
è che una volta stampata su carta non è possibile distinguere i dati 
OSM  da quelli proprietari.


--


Dario Zontini


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [OSM-talk-fr] Cimetière militaire

[Francescu GAROBY]

Bonsoir,
L'idée du tag sector est intéressante. D'ailleurs, comment sont tagués les
carrés musulmans/juifs/... dans les cimetières ? Avec "sector=XXX", aussi ?

Francescu

Le jeu. 24 janv. 2019 à 18:19, althio  a écrit :

> Une idée, ce serait :
> cemetary = military
> mais ça n'existe pas encore.
>
> Il y a une tentative polonaise de :
> cemetery:usage = war/military/family
> mais c'est confidentiel.
>
> Pourquoi non plus :
> cemetary = sector
> sector = military
> (ou cemetary:sector = military)
>
> On Thu, 24 Jan 2019 at 17:49, Florian LAINEZ  wrote:
>
>> Hello,
>> J'aimerai indiquer un carré militaire dans un cimetière :
>> https://www.openstreetmap.org/way/665897392
>>
>> Pour l'instant je l'ai taggué landuse=military mais je n'en suis pas très
>> fier :P
>> Je cherche le tag adéquat et n'ai pas trouvé.
>>
>> JOSM propose un preset "cimetière militaire" et rajoute dans ce cas :
>> historic=tomb
>> tomb=war_grave
>> Il arrive que ces tags soient appliqués à des cimetières, comme par
>> exemple https://www.openstreetmap.org/way/24893223
>> Or d'après moi ces tags désignent une tombe et non pas un cimetière / une
>> division de cimetière.
>>
>> Une idée ?
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>> ___
>> 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
>


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

Re: [OSM-talk-be] Status GRB-import tool ?

[Marc Gemis]

dat is inderdaad een van de workarounds, maar voor de een of andere
reden bleef JOSM bij mij toch nog die tags doorsturen. Ik zal wel iets
verkeerd gedaan hebben.

m.

On Thu, Jan 24, 2019 at 8:33 PM Jo  wrote:
>
> Ik voel me ook niet geroepen om die rol op me te nemen, maar ik heb wel een 
> suggestie voor tags die niet mogen worden doorgestuurd.
>
> JOSM heeft daar ondersteuning voor.
>
> Wat ik gewoonlijk doe is zulke tags created_by of odbl noemen, aangezien die 
> al in de lijst staan.
>
> De andere mogelijkheid is een key (tags.discardable) in de instellingen 
> aanpassen en dan worden ze vanzelf weggegooid voordat er data naar de server 
> gaat.
>
> mvg,
>
> Jo
>
>
> On Thu, Jan 24, 2019 at 8:13 PM Marc Gemis  wrote:
>>
>> Hallo Denis,
>>
>> Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
>> tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
>> druk momenteel.
>> Ik zal dan maar proberen te de situatie te schetsen:
>>
>> - de import mailing list had niet echt bezwaren, dus die hindernis is genomen
>> - de documentatie is volgens mij zo goed als af. De laatste beetjes
>> zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
>> - de tool heeft nog 2 problem (voor zover ik weet)
>> * er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
>> wel een eenvoudige workaround voor.
>> * niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
>> meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
>> met 3 ingangen en huisnummers 15, 16 en 17.
>> Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
>> om dit te verbeteren door een extra databank te laden in de tool. Dit
>> vraagt natuurlijk ontwikkelingstijd.
>>
>> Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
>> tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
>> foutieve data van externe bronnen, juich ik dat alleen maar toe.
>>
>> Ik weet echter niet of het enkel aan ons is om daarover te beslissen.
>>
>> Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
>> gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
>> in een groot deel van de provincie Antwerpen is de tool al niet meer
>> zo relevant.
>>
>> Misschien moet er gewoon iemand een datum prikken, een zaal met
>> internet verbinding voorzien, iemand uitnodigen die de nodige
>> toelichtingen kan geven en de "import" officieel starten.
>> Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
>> nemen om alles naast de ontwikkeling van de tool te organiseren en
>> daar dan ook voldoende tijd in stoppen.
>>
>> mvg
>>
>> m.
>>
>> p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
>> vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
>> om deze rol op te nemen.
>>
>> On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden  wrote:
>> >
>> > Dag iedereen,
>> >
>> > Graag wou ik nog eens polsen wat de status is van de GRB-import tool. 
>> > Ergens in 2017 is de publieke versie uitgezet omdat veel mensen hiermee 
>> > onbedoelde of verkeerde wijzigingen hebben gedaan.
>> >
>> > Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of 
>> > aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu 
>> > gebouwen te tracen als we ze later opnieuw moeten vervangen door de 
>> > "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot 
>> > toevoegen van nodes of features niet gerelateerd aan gebouwen.
>> >
>> > Groeten,
>> > Denis
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Status GRB-import tool ?

[Jo]

Als er zo'n Meetup georganiseerd wordt, zal ik alleszins wel proberen om
erbij te zijn.

Jo

On Thu, Jan 24, 2019 at 8:13 PM Marc Gemis  wrote:

> Hallo Denis,
>
> Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
> tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
> druk momenteel.
> Ik zal dan maar proberen te de situatie te schetsen:
>
> - de import mailing list had niet echt bezwaren, dus die hindernis is
> genomen
> - de documentatie is volgens mij zo goed als af. De laatste beetjes
> zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
> - de tool heeft nog 2 problem (voor zover ik weet)
> * er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
> wel een eenvoudige workaround voor.
> * niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
> meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
> met 3 ingangen en huisnummers 15, 16 en 17.
> Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
> om dit te verbeteren door een extra databank te laden in de tool. Dit
> vraagt natuurlijk ontwikkelingstijd.
>
> Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
> tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
> foutieve data van externe bronnen, juich ik dat alleen maar toe.
>
> Ik weet echter niet of het enkel aan ons is om daarover te beslissen.
>
> Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
> gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
> in een groot deel van de provincie Antwerpen is de tool al niet meer
> zo relevant.
>
> Misschien moet er gewoon iemand een datum prikken, een zaal met
> internet verbinding voorzien, iemand uitnodigen die de nodige
> toelichtingen kan geven en de "import" officieel starten.
> Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
> nemen om alles naast de ontwikkeling van de tool te organiseren en
> daar dan ook voldoende tijd in stoppen.
>
> mvg
>
> m.
>
> p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
> vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
> om deze rol op te nemen.
>
> On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden 
> wrote:
> >
> > Dag iedereen,
> >
> > Graag wou ik nog eens polsen wat de status is van de GRB-import tool.
> Ergens in 2017 is de publieke versie uitgezet omdat veel mensen hiermee
> onbedoelde of verkeerde wijzigingen hebben gedaan.
> >
> > Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of
> aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu
> gebouwen te tracen als we ze later opnieuw moeten vervangen door de
> "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot toevoegen
> van nodes of features niet gerelateerd aan gebouwen.
> >
> > Groeten,
> > Denis
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Status GRB-import tool ?

[Jo]

Ik voel me ook niet geroepen om die rol op me te nemen, maar ik heb wel een
suggestie voor tags die niet mogen worden doorgestuurd.

JOSM heeft daar ondersteuning voor.

Wat ik gewoonlijk doe is zulke tags created_by of odbl noemen, aangezien
die al in de lijst staan.

De andere mogelijkheid is een key (tags.discardable) in de instellingen
aanpassen en dan worden ze vanzelf weggegooid voordat er data naar de
server gaat.

mvg,

Jo


On Thu, Jan 24, 2019 at 8:13 PM Marc Gemis  wrote:

> Hallo Denis,
>
> Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
> tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
> druk momenteel.
> Ik zal dan maar proberen te de situatie te schetsen:
>
> - de import mailing list had niet echt bezwaren, dus die hindernis is
> genomen
> - de documentatie is volgens mij zo goed als af. De laatste beetjes
> zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
> - de tool heeft nog 2 problem (voor zover ik weet)
> * er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
> wel een eenvoudige workaround voor.
> * niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
> meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
> met 3 ingangen en huisnummers 15, 16 en 17.
> Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
> om dit te verbeteren door een extra databank te laden in de tool. Dit
> vraagt natuurlijk ontwikkelingstijd.
>
> Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
> tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
> foutieve data van externe bronnen, juich ik dat alleen maar toe.
>
> Ik weet echter niet of het enkel aan ons is om daarover te beslissen.
>
> Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
> gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
> in een groot deel van de provincie Antwerpen is de tool al niet meer
> zo relevant.
>
> Misschien moet er gewoon iemand een datum prikken, een zaal met
> internet verbinding voorzien, iemand uitnodigen die de nodige
> toelichtingen kan geven en de "import" officieel starten.
> Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
> nemen om alles naast de ontwikkeling van de tool te organiseren en
> daar dan ook voldoende tijd in stoppen.
>
> mvg
>
> m.
>
> p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
> vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
> om deze rol op te nemen.
>
> On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden 
> wrote:
> >
> > Dag iedereen,
> >
> > Graag wou ik nog eens polsen wat de status is van de GRB-import tool.
> Ergens in 2017 is de publieke versie uitgezet omdat veel mensen hiermee
> onbedoelde of verkeerde wijzigingen hebben gedaan.
> >
> > Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of
> aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu
> gebouwen te tracen als we ze later opnieuw moeten vervangen door de
> "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot toevoegen
> van nodes of features niet gerelateerd aan gebouwen.
> >
> > Groeten,
> > Denis
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell

[Hubert87]

Hallo Flo,

das "Problem" mit bicycle=designated/yes ist leider so eine Sache.

Einen eindeutigen Tag "Dieser Radweg ist benutzungspflichtig" gibt es 
leider immer noch nicht.


Stattdessen wird versucht dies mit der Unterscheidung zu bicycle=yes 
(imo unzuverlässig) zu erreichen. (Und von mir über traffic_sign=* und 
Straßenbezug ("cycleway/path=sidepath"))


Im Grunde wird versucht durch "yes" alle nicht-benutzungspflichtigen 
Radwege zu kennzeichnen, so dass für die benutzungspflichtigen Radwege 
nur "designated" übrig bleibt.


An highway=cycleway oder cycleway=track/lane funktioniert dies noch, da 
die Eigenschaft "Radweg" durch das "cycleway" erreicht wird.


Bei highway=path klappt das aber leider nicht mehr, da hier nur über das 
"designated" gesagt wird, ich bin (exklusiv*)für Radfahrer gewidmet. (* 
Exklusivität kann sich addieren, Z.B. mit Fußgängern). Dazu sei noch 
gesagt, dass "designated" zusammen mit und für highway=path eingeführt 
wurde.


Schwierig wird es auch mit blau-beschilderten Radwegen die Querfeld ein 
(also eigenständig) verlaufen, da diese an sich - mangels Fahrbahn - 
nicht benutzungspflichtig sein können; man hat ja keine Alternative. 
(Das gilt das auch für highway=cycleway, bicycle=yes/designated.)


Zur Vollständigkeit sei noch gesagt, dass auch noch bicycle=official im 
Umlauf ist, mit dem man (je nach Verständnis) alle "echten" (StVO) 
Radwege und/oder alle blau-beschilderten Radwege und/oder alle Wege mit 
Radrouten getagged wurden. Bringt aber leider auch nicht viel in 
Hinblick auf die Benutzungspflicht.


Vielleicht sollte ich mein Proposal nochmal überarbeiten und neu 
einbringen. 
https://wiki.openstreetmap.org/wiki/Proposed_features/obligatory_usage


Eventuel "obligatory(_use)"="bicycle;foot". Z.B. 
"cycleway:right:obligatory(_use)"="bicycle" oder wie auf der 
Discussionsseite vorgeschlagen in Form von bicycle:obligatory="yes/no" 
z.B: "cycleway:right:bicycle:obligatory"="yes/no"


Gruß

Hubert87



Am 24.01.2019 um 08:23 schrieb Florian Lohoff:

On Wed, Jan 23, 2019 at 10:03:39PM +0100, Hubert87 wrote:

Hallo Flo,

bei dem Thema gibt es leider im Detail keinen abschließenden Konsens in der
entsprechenden Community.

Das Lübecker Schema hast Du soweit, wie Du es beschrieben hast, im Kern

Was mich halt immer stutzig macht das die existenz von etwas durch die
absenz eines Tags angedeuted wird.

Damit sind die zustände "nicht vollständig erfasst" und "da ist was aber
es ist anders" nicht unterscheidbar.


richtig verstanden. Bitte schaue Dir im Vergleich dazu auch nochmal die
Seite
https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren
an. (Disclaimer: vor einiger Zeit hauptsächlich von mir überarbeitet.)

Für mich ergibt sich nach 2 Minuten der erste Widerspruch zum Lübecker
Modell. Für mich war immer - "angeordnet" -> "designated". Nicht
angeordenet aber benutzbar "yes".

https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren
Getrennter Fuß- und Radweg ohne Benutzungspflicht

cycleway:right:bicycle=designated

In dem Modell nur durch traffic_sign=none erkennbar.

*Soifz*

Flo


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

Re: [OSM-talk-be] Status GRB-import tool ?

[Marc Gemis]

Hallo Denis,

Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
druk momenteel.
Ik zal dan maar proberen te de situatie te schetsen:

- de import mailing list had niet echt bezwaren, dus die hindernis is genomen
- de documentatie is volgens mij zo goed als af. De laatste beetjes
zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
- de tool heeft nog 2 problem (voor zover ik weet)
* er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
wel een eenvoudige workaround voor.
* niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
met 3 ingangen en huisnummers 15, 16 en 17.
Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
om dit te verbeteren door een extra databank te laden in de tool. Dit
vraagt natuurlijk ontwikkelingstijd.

Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
foutieve data van externe bronnen, juich ik dat alleen maar toe.

Ik weet echter niet of het enkel aan ons is om daarover te beslissen.

Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
in een groot deel van de provincie Antwerpen is de tool al niet meer
zo relevant.

Misschien moet er gewoon iemand een datum prikken, een zaal met
internet verbinding voorzien, iemand uitnodigen die de nodige
toelichtingen kan geven en de "import" officieel starten.
Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
nemen om alles naast de ontwikkeling van de tool te organiseren en
daar dan ook voldoende tijd in stoppen.

mvg

m.

p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
om deze rol op te nemen.

On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden  wrote:
>
> Dag iedereen,
>
> Graag wou ik nog eens polsen wat de status is van de GRB-import tool. Ergens 
> in 2017 is de publieke versie uitgezet omdat veel mensen hiermee onbedoelde 
> of verkeerde wijzigingen hebben gedaan.
>
> Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of 
> aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu 
> gebouwen te tracen als we ze later opnieuw moeten vervangen door de 
> "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot toevoegen 
> van nodes of features niet gerelateerd aan gebouwen.
>
> Groeten,
> Denis
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [Talk-ca] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 11:03 AM, Danny McDonald  wrote:
> A place does not need to incorporated to be a place=town, city, village.  
> That is not how it works anywhere in OSM - there are many unincorporated 
> places with these tags, worldwide.  The tagging in Ottawa is a good guide, 
> with e.g. Richmond a village, but e.g. Centretown and Stittsville 
> place=suburbs, based on distinctness.

I don't believe I said it did, I do believe I said that a city is always 
incorporated, a town or village, "maybe."

And, as I also said, "local tagging as a consensus or guide" is something to 
consider.  This isn't alway black-and-white, nor easy.  As we "do our best," 
things eventually emerge as correct, though it usually takes some time and 
effort to get there.  (Consensus does).

SteveA

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

Re: [Talk-ca] Place Tagging

[Danny McDonald]

A place does not need to incorporated to be a place=town, city, village.
That is not how it works anywhere in OSM - there are many unincorporated
places with these tags, worldwide.  The tagging in Ottawa is a good guide,
with e.g. Richmond a village, but e.g. Centretown and Stittsville
place=suburbs, based on distinctness.
DannyMcD

On Thu, Jan 24, 2019, 1:53 PM OSM Volunteer stevea <
stevea...@softworkers.com wrote:

> On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> > My understanding of place tagging is that place=city, place=town, and
> place=village are for distinct urban settlements, whether or not they are
> separate municipalities.
>
> Correct, in that these tags can be placed upon a node, way or relation (if
> a boundary relation, a node with role admin_centre is correct).  Sometimes
> a way (often a closed polygon) is not precisely known, or is, but license
> restrictions prevent those data from entering OSM.  In that case, a simple
> node tagged place=* with appropriate value is used, as documented at
> https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful
> regarding "incorporated" areas; see below.
>
> > Place=suburb is for large parts of urban settlements (such as North York
> in Toronto, or Kanata in Ottawa).
>
> While I am not a political scientist, I did participate in the development
> of consensus in the United_States in
> https://wiki.osm.org/wiki/United_States_admin_level , a complex task
> indeed (and I'll say we only have it "largely correct," certainly not
> "exactly correct").  While Canada has similarities, it certainly is unique
> in admin_level, appropriately documented at
> https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept
> found in many countries, Canada included, is that of "incorporation" —
> whether an urban settlement is a "body corporate."  Cities always are,
> suburbs and towns, depending on differing context for each of these, may or
> may not be.
>
> > Whether to classify a place as a place=city/town/village or place=suburb
> depends on the facts on the ground (I.e. whether a place is part of a
> larger urban settlement), and not primarily on municipal/administrative
> boundaries.
>
> I can't speak for all of Canada, but I can speak to what OSM documents in
> our place=* wiki:  that urban and rural populated places are distinguished
> by two separate tables there, so it is useful to understand how OSM
> characterizes these as slightly different (with specific tags in each
> table).  This is regardless of how any particular country might use the
> same names.  For example, place=suburb has a very specific semantic as it
> is used in OSM, contrasted with how "real world" "suburb" might mean an
> incorporated (smaller) city near a (larger) city, OR it might mean a
> district/area/small region INSIDE of an incorporated city (how OSM means
> it).  We must be careful to tag in OSM with how OSM means things, mapping
> our "real world" semantics onto OSM semantics.
>
> > Municipal boundaries might be somewhat relevant in determining if a
> place is distinct (e.g. Vaughan is a city, not a suburb), but they are a
> relatively minor factor.
>
> I don't know what this means exactly.  Municipal boundaries ARE EXACTLY
> relevant in determining if a place is distinct:  they literally distinguish
> it.  In "real world speak" Vaughn might be called a suburb, but unless it
> meets OSM's place=suburb definition, it shouldn't be tagged that way in
> OSM.  This isn't minor, it is "either correct or incorrect."
>
> > The main way that municipal names are mapped is through admin boundary
> relations, not place nodes (although many municipalities have the same name
> as their largest urban settlement, of course).
>
> Yes, this is true, although for many smaller human settlements (and some
> larger ones), place nodes simply "will have to" suffice.
>
> > The way to distinguish between a place=city, place=town, and
> place=village is population size, with nearby places shading things a bit
> (so a smaller population size qualifies for a place=town in Northern
> Ontario).  Very roughly, a city has population >50k, a town has population
> 5k-50k, and a village is <5k.
>
> OSM's place wiki notes that a village is more like "200 to town size" so
> that 5k edge is fuzzy.  The USA admin_level wiki documents some "rules of
> thumb" here, but, yes, these can be rough, and are sometimes "stretched"
> (or "shaded" as you say) a bit so that wide-zoom views of very rural areas
> (e.g. northern Ontario) show settlements a bit more clearly.
>
> > There seems to be a persistent mis-understanding of this scheme, where
> various editors (mainly @OntarioEditor and various other accounts
> controlled by them) believe that place=city/town/village are for
> municipalities, whether or not the municipality has one major urban
> settlement with the same name as the municipality or not.  They are also
> tagging all unincorporated places in a municipality as place=suburb,
> 

Re: [Talk-ca] Ongoing Place Reclassification needs to be stopped, possibly reverted

[Martin Chalifoux via Talk-ca]

I know in Quebec the place=village tag has been adopted to tag the 
municipalities other than town, cities and suburb, regardless of population. I 
think, but don’t know for sure, the main reason for this is actually the 
rendering engine(s). The place=village tag get a nice rendering that allow to 
identify the municipalities visually on the map. When the municipality, label  
and other tags are used (instead of village), they render very small and are 
not useful. There is a need for municipality names to stand out at a descent 
zoom level on the map, regardless of population. That is important for 
navigating the territory. So I guess my bit of advise is to not only look at 
the pure logic of OSM tagging to understand what is being done in the field and 
also how rendering is done and maybe you will get a better understanding of why 
people do that they do. Now there are tons of rendering engines beside 
openstreetmap.org  but that one is a good place to 
start with.

I also agree that a more consistent scheme needs to be worked out. It is hard 
to maintain the current one. In Quebec there has been mergers over the years 
and often multiple villages are now in one municipality and both informations 
need to show in OSM somehow.

Martin

> On Jan 24, 2019, at 13:24, Danny McDonald  wrote:
> 
> Repeating this, since it seemed to get bumped by all the building import 
> talk.  Now with a catchier subject line. 
> DannyMcD
> 
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.  Place=suburb is for large parts of urban 
> settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether to 
> classify a place as a place=city/town/village or place=suburb depends on the 
> facts on the ground (I.e. whether a place is part of a larger urban 
> settlement), and not primarily on municipal/administrative boundaries.   
> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.  The main way that municipal names are mapped is through admin 
> boundary relations, not place nodes (although many municipalities have the 
> same name as their largest urban settlement, of course).  The way to 
> distinguish between a place=city, place=town, and place=village is population 
> size, with nearby places shading things a bit (so a smaller population size 
> qualifies for a place=town in Northern Ontario).  Very roughly, a city has 
> population >50k, a town has population 5k-50k, and a village is <5k.
> 
> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, consider Minto 
> (https://www.openstreetmap.org/relation/7486154 
> ) in southwest Ontario.  It 
> has two distinct population centres, Harriston and Palmerston.  In the OSM 
> scheme, both are tagged as place=town, and the municipality name Minto (since 
> it does not correspond to a distinct urban settlement) does not get a place 
> tag (except perhaps as a place=municipality at the municipal offices).  The 
> mistaken scheme is to tag Harriston and Palmerston as place=suburb, and 
> create a place=town node for Minto.
> 
> Any thoughts?
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.

Correct, in that these tags can be placed upon a node, way or relation (if a 
boundary relation, a node with role admin_centre is correct).  Sometimes a way 
(often a closed polygon) is not precisely known, or is, but license 
restrictions prevent those data from entering OSM.  In that case, a simple node 
tagged place=* with appropriate value is used, as documented at 
https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful regarding 
"incorporated" areas; see below.

> Place=suburb is for large parts of urban settlements (such as North York in 
> Toronto, or Kanata in Ottawa).

While I am not a political scientist, I did participate in the development of 
consensus in the United_States in 
https://wiki.osm.org/wiki/United_States_admin_level , a complex task indeed 
(and I'll say we only have it "largely correct," certainly not "exactly 
correct").  While Canada has similarities, it certainly is unique in 
admin_level, appropriately documented at 
https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept found 
in many countries, Canada included, is that of "incorporation" — whether an 
urban settlement is a "body corporate."  Cities always are, suburbs and towns, 
depending on differing context for each of these, may or may not be.

> Whether to classify a place as a place=city/town/village or place=suburb 
> depends on the facts on the ground (I.e. whether a place is part of a larger 
> urban settlement), and not primarily on municipal/administrative boundaries.

I can't speak for all of Canada, but I can speak to what OSM documents in our 
place=* wiki:  that urban and rural populated places are distinguished by two 
separate tables there, so it is useful to understand how OSM characterizes 
these as slightly different (with specific tags in each table).  This is 
regardless of how any particular country might use the same names.  For 
example, place=suburb has a very specific semantic as it is used in OSM, 
contrasted with how "real world" "suburb" might mean an incorporated (smaller) 
city near a (larger) city, OR it might mean a district/area/small region INSIDE 
of an incorporated city (how OSM means it).  We must be careful to tag in OSM 
with how OSM means things, mapping our "real world" semantics onto OSM 
semantics.

> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.

I don't know what this means exactly.  Municipal boundaries ARE EXACTLY 
relevant in determining if a place is distinct:  they literally distinguish it. 
 In "real world speak" Vaughn might be called a suburb, but unless it meets 
OSM's place=suburb definition, it shouldn't be tagged that way in OSM.  This 
isn't minor, it is "either correct or incorrect."

> The main way that municipal names are mapped is through admin boundary 
> relations, not place nodes (although many municipalities have the same name 
> as their largest urban settlement, of course).

Yes, this is true, although for many smaller human settlements (and some larger 
ones), place nodes simply "will have to" suffice.

> The way to distinguish between a place=city, place=town, and place=village is 
> population size, with nearby places shading things a bit (so a smaller 
> population size qualifies for a place=town in Northern Ontario).  Very 
> roughly, a city has population >50k, a town has population 5k-50k, and a 
> village is <5k.

OSM's place wiki notes that a village is more like "200 to town size" so that 
5k edge is fuzzy.  The USA admin_level wiki documents some "rules of thumb" 
here, but, yes, these can be rough, and are sometimes "stretched" (or "shaded" 
as you say) a bit so that wide-zoom views of very rural areas (e.g. northern 
Ontario) show settlements a bit more clearly.

> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, 

[Talk-ca] Ongoing Place Reclassification needs to be stopped, possibly reverted

[Danny McDonald]

Repeating this, since it seemed to get bumped by all the building import
talk.  Now with a catchier subject line.
DannyMcD

My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

Any thoughts?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canada Building imports wiki page

[Nate Wessel]

John,

I mentioned several times in the various email threads that I planned to 
make substantial changes to the wiki. If you think something I added is 
a value judgment, I encourage you to point it out, on the wiki itself 
ideally. I think I've mostly been restructuring the page (without 
deleting much) and adding content on data quality.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/24/19 12:56 PM, OSM Volunteer stevea wrote:

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:

You seem to have made rather large changes without consultation including 
changing the title of the project.  You have also added some value judgments.  
A number of people were involved in the original and it might have been nice to 
consult with them before making such drastic changes.  The word consensus 
springs to mind.

I make no comment on whether the changes are good or bad merely extensive 
without apparent consultation.

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve consensus."  
Sometimes, it makes sense to have an off-list email conversation in a one-on-one or one-on-many 
fashion.  Thanks.

SteveA
California


On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea  
wrote:

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:

You seem to have made rather large changes without consultation including 
changing the title of the project.  You have also added some value judgments.  
A number of people were involved in the original and it might have been nice to 
consult with them before making such drastic changes.  The word consensus 
springs to mind.

I make no comment on whether the changes are good or bad merely extensive 
without apparent consultation.

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve consensus."  
Sometimes, it makes sense to have an off-list email conversation in a one-on-one or one-on-many 
fashion.  Thanks.

SteveA
California


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

[Talk-ca] Canada Building Import wiki page

[Nate Wessel]

Hi all,

I just want to let everyone know that I moved the OSM wiki page for the 
Canadian building import, much discussed of late on this list. My hope 
is that this name is easier to search and more clearly conveys what we 
are trying to do.


All history for the page is preserved and a redirect has been created. 
I'll check for any remaining broken links in just a second.


Original:
https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no

Current:
https://wiki.openstreetmap.org/wiki/Canada_Building_Import

If you haven't checked the wiki in the last week, there have been a lot 
of changes, and any contributions from users with experience working 
with this data would be greatly appreciated. The goal is to have crystal 
clear documentation of the import plan which follows the guidelines laid 
out on the import guidelines page.


Best,

--
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

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

Re: [Talk-ca] Canada Building imports wiki page

[OSM Volunteer stevea]

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
> You seem to have made rather large changes without consultation including 
> changing the title of the project.  You have also added some value judgments. 
>  A number of people were involved in the original and it might have been nice 
> to consult with them before making such drastic changes.  The word consensus 
> springs to mind.
> 
> I make no comment on whether the changes are good or bad merely extensive 
> without apparent consultation. 

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve 
consensus."  Sometimes, it makes sense to have an off-list email conversation 
in a one-on-one or one-on-many fashion.  Thanks.

SteveA
California

> On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea  
> wrote:
> 
> On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
>> You seem to have made rather large changes without consultation including 
>> changing the title of the project.  You have also added some value 
>> judgments.  A number of people were involved in the original and it might 
>> have been nice to consult with them before making such drastic changes.  The 
>> word consensus springs to mind.
>> 
>> I make no comment on whether the changes are good or bad merely extensive 
>> without apparent consultation. 
> 
> John, much consensus is achieved in wiki Discussion(s), simply click the 
> Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
> notice that there are four threads/sections under Discussion there already.
> 
> If some "number of people" were involved in the original, they are perfectly 
> welcome to join there.
> 
> I'm not saying "don't do this in talk-ca" I am saying "there are often 
> more-appropriate (vs. less-appropriate) places to have a discussion to 
> achieve consensus."  Sometimes, it makes sense to have an off-list email 
> conversation in a one-on-one or one-on-many fashion.  Thanks.
> 
> SteveA
> California


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

Re: [Talk-ca] Canada Building imports wiki page

[john whelan]

You seem to have made rather large changes without consultation including
changing the title of the project.  You have also added some value
judgments.  A number of people were involved in the original and it might
have been nice to consult with them before making such drastic changes.
The word consensus springs to mind.

I make no comment on whether the changes are good or bad merely extensive
without apparent consultation.

Cheerio John

On Thu, 24 Jan 2019 at 12:13, Nate Wessel  wrote:

> Hi all,
>
> Just a heads up that I've moved the page documenting the plan to import
> buildings across Canada, much discussed on this list of late. The idea is
> that the new title is more concise, easily searchable, and clearly explains
> what we're trying to do. All page history has been preserved and a redirect
> has been put in place.
>
> Previous:
> https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no
>
> Current: https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
> If you haven't looked at the wiki lately, there have been some big
> changes, and more on the way. The goal is to get this page to clearly and
> explicitly document the import plan, not only to guide editors, but also to
> set people's minds at ease, answer any questions, and as a useful
> description of where all this data came from once the import is over.
>
> Please feel encouraged to edit the page to get it in line with the
> documentation required for import as described on the import guidelines
> page.
>
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Best,
> --
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Cimetière militaire

[althio]

Une idée, ce serait :
cemetary = military
mais ça n'existe pas encore.

Il y a une tentative polonaise de :
cemetery:usage = war/military/family
mais c'est confidentiel.

Pourquoi non plus :
cemetary = sector
sector = military
(ou cemetary:sector = military)

On Thu, 24 Jan 2019 at 17:49, Florian LAINEZ  wrote:

> Hello,
> J'aimerai indiquer un carré militaire dans un cimetière :
> https://www.openstreetmap.org/way/665897392
>
> Pour l'instant je l'ai taggué landuse=military mais je n'en suis pas très
> fier :P
> Je cherche le tag adéquat et n'ai pas trouvé.
>
> JOSM propose un preset "cimetière militaire" et rajoute dans ce cas :
> historic=tomb
> tomb=war_grave
> Il arrive que ces tags soient appliqués à des cimetières, comme par
> exemple https://www.openstreetmap.org/way/24893223
> Or d'après moi ces tags désignent une tombe et non pas un cimetière / une
> division de cimetière.
>
> Une idée ?
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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

[Talk-ca] Fwd: Ongoing Canadian building import needs to be stopped, possibly reverted

[john whelan]

We're over the 40 k limit again so I trimmed it.

I get the impression that just adding the building outline or even an
approximation of a building outline adds value to the map.

My own house has a cantilever on the back so the upper story extends beyond
the basement outline.  It also has a porch on the front which has a
basement.

My personal view is a rectangle that represents the basic shape is more
than acceptable however I can appreciate that some might like to have a
greater level of detail.

I personally feel this can be added later.

Cheerio John

On Thu, Jan 24, 2019, 12:03 PM James  That is incorrect, some building parts could be bigger if they are
> surrounding the building as an overhang etc. You can't assume building will
> be bigger
>
> On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel 
>> Is it sufficient to tag fragments as building:part without indicating
>> which part or how many stories? If the data is properly structured, this
>> seems like something that could be handled in preprocessing by checking for
>> overlapping polygons. It looks like perhaps we might just have to find the
>> largest part for the footprint (building=yes) and any intersecting smaller
>> buildings (building:part=yes).
>>
>> We might also need to generate some building relations for more complex
>> features.
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>>
>> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
>> It's not in the import wiki though since whoever wrote it didn't know
>> about it at the time.
>> Here's what I mean by mapping 3D features in our case. Say there is a
>> residential tower on a podium. In the StatsCan data usually you would find
>> both of these outlines - large podium outline and smaller tower outline
>> inside it. They would both be tagged with "building=yes" tag. Obviously we
>> can't upload that as-is. We can either just remove tower outline leaving
>> only 2D podium outline. Or, we can tag the tower outline with
>> "building:part=yes". Someone local can add other tags to it later on, such
>> as "building:levels", "building:material", "building:min_level",
>> "addr:housenumber" (if there are two towers on one podium with different
>> house numbers for example), etc. I find the latter approach to be the right
>> one.
>>
>> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>>
>>> Hi Yaro,
>>>
>>> I just had a chance to look at the documentation on the source data and
>>> I wasn't able to find anything about 3D features or parts of buildings
>>> being mapped separately. Are you guessing here, or is there documentation
>>> on this? If so can you point us to it?
>>>
>>> In any case, the big shapefiles from StatsCan don't provide enough
>>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>>> these from the import unless they can be brought in from another source
>>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>>
>>> Thanks,
>>> Nate Wessel
>>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>>> NateWessel.com 
>>>
>>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>>
>>> Jarek,
>>> There is no question we want this data. I went through much of it in
>>> Toronto and Kingston and I found it to be very good, consistent and
>>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>>> features (when several buildings appear overlapped in the dataset) but you
>>> just need to be familiar with `building:part` tag to sort through it. I
>>> haven't looked at other provinces but in Ontario I really have no
>>> complaints about dataset quality whatsoever. Also I don't get Nate's
>>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>>> detailed.
>>>
>>>
>>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Cimetière militaire

[marc marc]

Le 24.01.19 à 17:48, Florian LAINEZ a écrit :
> un carré militaire dans un cimetière : 
> https://www.openstreetmap.org/way/665897392
> Pour l'instant je l'ai taggué landuse=military

en première impression, je trouvais cela correct :
cette partie du cimetière est une conséquence de l’existence
d'une armée et donc une "utilisation" de celle-ci même
la zone contient aussi parfois des civils.

mais il y a un soucis. l'ensemble du cimetière est tagé
avec landuse=cemetery ce qui me semble quand même le landuse réel
et je trouve encore moins bien de superposer 2 landuse

> historic=tomb
> tomb=war_grave
> ces tags désignent une tombe

on peux facilement les adapter
historic=cemetery https://taginfo.openstreetmap.org/tags/historic=cemetery
cemetery=war_cemetery (Ca fait un peu redondant)
ou cemetery=military ?

on peux éventuellement ajouter historic:period pour lier au conflit
ou cemetery:conflict (non documenté)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ca] Canada Building imports wiki page

[Nate Wessel]

Hi all,

Just a heads up that I've moved the page documenting the plan to import 
buildings across Canada, much discussed on this list of late. The idea 
is that the new title is more concise, easily searchable, and clearly 
explains what we're trying to do. All page history has been preserved 
and a redirect has been put in place.


Previous: 
https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no 



Current: https://wiki.openstreetmap.org/wiki/Canada_Building_Import

If you haven't looked at the wiki lately, there have been some big 
changes, and more on the way. The goal is to get this page to clearly 
and explicitly document the import plan, not only to guide editors, but 
also to set people's minds at ease, answer any questions, and as a 
useful description of where all this data came from once the import is over.


Please feel encouraged to edit the page to get it in line with the 
documentation required for import as described on the import guidelines 
page.


https://wiki.openstreetmap.org/wiki/Import/Guidelines

Best,

--
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

That is incorrect, some building parts could be bigger if they are
surrounding the building as an overhang etc. You can't assume building will
be bigger

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel  Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper offset can be difficult to establish in big
>>> cities where GPS signal is erratic. Pragmatically, I can tell you 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

>>It looks like perhaps we might just have to find the largest part for the
footprint (building=yes) and any intersecting smaller buildings
(building:part=yes).
Yes, that's what I usually do. I also sometimes delete non-important
building parts that don't add anything valuable to the map but only
complicate things. Not sure how to better explain that in the wiki, it's a
personal judgement thing I guess.


On Thu, Jan 24, 2019 at 11:49 AM Nate Wessel  wrote:

> Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Kevin Farrugia]

Data is currently stored in OSM by mappers this way, regardless of the
source. I don't think a height or which part is needed to use the building
part tags. It provides the basis for later additions should a mapper be so
inclined to add it.

---
Kevin Farrugia

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel  Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Is it sufficient to tag fragments as building:part without indicating 
which part or how many stories? If the data is properly structured, this 
seems like something that could be handled in preprocessing by checking 
for overlapping polygons. It looks like perhaps we might just have to 
find the largest part for the footprint (building=yes) and any 
intersecting smaller buildings (building:part=yes).


We might also need to generate some building relations for more complex 
features.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/24/19 11:40 AM, Yaro Shkvorets wrote:

OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
It's not in the import wiki though since whoever wrote it didn't know 
about it at the time.
Here's what I mean by mapping 3D features in our case. Say there is a 
residential tower on a podium. In the StatsCan data usually you would 
find both of these outlines - large podium outline and smaller tower 
outline inside it. They would both be tagged with "building=yes" tag. 
Obviously we can't upload that as-is. We can either just remove tower 
outline leaving only 2D podium outline. Or, we can tag the tower 
outline with "building:part=yes". Someone local can add other tags to 
it later on, such as "building:levels", "building:material", 
"building:min_level", "addr:housenumber" (if there are two towers on 
one podium with different house numbers for example), etc. I find the 
latter approach to be the right one.


On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel > wrote:


Hi Yaro,

I just had a chance to look at the documentation on the source
data and I wasn't able to find anything about 3D features or parts
of buildings being mapped separately. Are you guessing here, or is
there documentation on this? If so can you point us to it?

In any case, the big shapefiles from StatsCan don't provide enough
information to reconstruct any 3D geometries, so I'd be inclined
to remove these from the import unless they can be brought in from
another source with better documentation / attribute tagging.
(i.e. City of Toronto?)

Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it
in Toronto and Kingston and I found it to be very good,
consistent and precise. Time-wise it's somewhat current with 2016
ESRI imagery (sometimes ahead, sometimes slightly behind) and is
well-aligned with it. It offers 3D features (when several
buildings appear overlapped in the dataset) but you just need to
be familiar with `building:part` tag to sort through it. I
haven't looked at other provinces but in Ontario I really have no
complaints about dataset quality whatsoever. Also I don't get
Nate's "wildly unsimplified geometries" comment. IMO geometries
are just perfectly detailed.


On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski
mailto:ja...@piorkowski.ca>> wrote:

Some more thoughts from me.

Building outlines, particularly for single-family
subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map
manually.

My parents' house is now on OSM - accurately. They live in a
city with
about 10,000 buildings, and about 0.5 active mappers. This
wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm
detecting
objects from imagery could be suggested, but this has not
been very
accurate in OSM in the past, even when there is decent
imagery. The
only other feasible data source is government, where they
have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the
buildings
manually. In practice what I've seen done in Toronto is that
bigger
buildings are mapped on best-effort basis from survey and
imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their
house. A
building might be legally split into two different properties
without
it being evident from the street. Imagery is out of date the
day after
it's taken, and proper offset can be difficult to establish
in big
cities where GPS signal 

[OSM-talk-fr] Cimetière militaire

[Florian LAINEZ]

Hello,
J'aimerai indiquer un carré militaire dans un cimetière :
https://www.openstreetmap.org/way/665897392

Pour l'instant je l'ai taggué landuse=military mais je n'en suis pas très
fier :P
Je cherche le tag adéquat et n'ai pas trouvé.

JOSM propose un preset "cimetière militaire" et rajoute dans ce cas :
historic=tomb
tomb=war_grave
Il arrive que ces tags soient appliqués à des cimetières, comme par exemple
https://www.openstreetmap.org/way/24893223
Or d'après moi ces tags désignent une tombe et non pas un cimetière / une
division de cimetière.

Une idée ?

-- 

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[John Whelan]

>they can be brought in from another source with better documentation / 
attribute tagging. (i.e. City of Toronto?)


I understand The City of Toronto Open Data License has been submitted to 
the OSM Legal Working Group some time ago.  The Federal Government 2.0 
license and the City of Ottawa Open Data license have been approved but 
they have requested any variations be submitted to them for review.


Translation even though some of this data came from the City of Toronto 
originally my understanding is currently we can't use open data from 
Toronto directly.  I believe it was a Toronto mapper who submitted all 
three licenses to the Legal Working Group originally.


There was quite a bit of discussion during the Ottawa Open Data import 
about licensing and some assumptions that had been made were found to be 
not quite as has been assumed.


Cheerio John

Nate Wessel wrote on 2019-01-24 11:14 AM:


Hi Yaro,

I just had a chance to look at the documentation on the source data 
and I wasn't able to find anything about 3D features or parts of 
buildings being mapped separately. Are you guessing here, or is there 
documentation on this? If so can you point us to it?


In any case, the big shapefiles from StatsCan don't provide enough 
information to reconstruct any 3D geometries, so I'd be inclined to 
remove these from the import unless they can be brought in from 
another source with better documentation / attribute tagging. (i.e. 
City of Toronto?)


Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it in 
Toronto and Kingston and I found it to be very good, consistent and 
precise. Time-wise it's somewhat current with 2016 ESRI imagery 
(sometimes ahead, sometimes slightly behind) and is well-aligned with 
it. It offers 3D features (when several buildings appear overlapped 
in the dataset) but you just need to be familiar with `building:part` 
tag to sort through it. I haven't looked at other provinces but in 
Ontario I really have no complaints about dataset quality whatsoever. 
Also I don't get Nate's "wildly unsimplified geometries" comment. IMO 
geometries are just perfectly detailed.



On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski > wrote:


Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as
seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city
with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm
detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their
house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day
after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you
from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data
source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so
  

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 114, Udgave 3

[Anders Hedelund]

Uhadada.

Jeg prøvede bare (naivt?) at trække de ca 4600 stednavne, GEUS 
kender/anvender, over til supplement af de 10-15-stykker, der (i 
hånden?) allerede er oprettet på OSM. Jeg blev ret glad da jeg opdagede, 
at måske 90% af alle koordinater var ganske nøjagtige med mange 
decimaler. Resten er af typen "bjerggruppen i det fjerne, ca pos. 
sådan-og-sådan, kaldes xxx"...


Tænkte det var et super-startpunkt. Og området synes ganske rigtigt 
indtil nu  stort set alene at have (haft) danske/norske/internationale 
stednavne..


Men hvis/når der er politik i sager vil jeg ikke røre dem med en 
ildtang, så jeg lukker. Roger over and out...




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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
It's not in the import wiki though since whoever wrote it didn't know about
it at the time.
Here's what I mean by mapping 3D features in our case. Say there is a
residential tower on a podium. In the StatsCan data usually you would find
both of these outlines - large podium outline and smaller tower outline
inside it. They would both be tagged with "building=yes" tag. Obviously we
can't upload that as-is. We can either just remove tower outline leaving
only 2D podium outline. Or, we can tag the tower outline with
"building:part=yes". Someone local can add other tags to it later on, such
as "building:levels", "building:material", "building:min_level",
"addr:housenumber" (if there are two towers on one podium with different
house numbers for example), etc. I find the latter approach to be the right
one.

On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:

> Hi Yaro,
>
> I just had a chance to look at the documentation on the source data and I
> wasn't able to find anything about 3D features or parts of buildings being
> mapped separately. Are you guessing here, or is there documentation on
> this? If so can you point us to it?
>
> In any case, the big shapefiles from StatsCan don't provide enough
> information to reconstruct any 3D geometries, so I'd be inclined to remove
> these from the import unless they can be brought in from another source
> with better documentation / attribute tagging. (i.e. City of Toronto?)
>
> Thanks,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>
> Jarek,
> There is no question we want this data. I went through much of it in
> Toronto and Kingston and I found it to be very good, consistent and
> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
> features (when several buildings appear overlapped in the dataset) but you
> just need to be familiar with `building:part` tag to sort through it. I
> haven't looked at other provinces but in Ontario I really have no
> complaints about dataset quality whatsoever. Also I don't get Nate's
> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
> detailed.
>
>
> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
> wrote:
>
>> Some more thoughts from me.
>>
>> Building outlines, particularly for single-family subdivisions as seen
>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>
>> My parents' house is now on OSM - accurately. They live in a city with
>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>> been completed manually in the next 5 years.
>>
>> An option to do this automatically with a computer algorithm detecting
>> objects from imagery could be suggested, but this has not been very
>> accurate in OSM in the past, even when there is decent imagery. The
>> only other feasible data source is government, where they have such
>> data more or less.
>>
>> The alternative is of course the opinion that we should not have
>> building outlines until someone goes through and adds the buildings
>> manually. In practice what I've seen done in Toronto is that bigger
>> buildings are mapped on best-effort basis from survey and imagery,
>> while areas of single-family houses are left blank. This isn't
>> _wrong_, and maybe some prefer this.
>>
>> I would also like to note that building outlines will _never_ be
>> completely verifiably up to date. I can't go into most people's
>> backyards and verify that there isn't a new addition on their house. A
>> building might be legally split into two different properties without
>> it being evident from the street. Imagery is out of date the day after
>> it's taken, and proper offset can be difficult to establish in big
>> cities where GPS signal is erratic. Pragmatically, I can tell you from
>> personal experience that building data in lovingly-mapped Berlin is
>> also worse than 1 meter accuracy. So again: best effort.
>>
>> What do we get from having buildings? A sense of land use (arguably
>> replaceable with larger landuse areas). A way to roughly estimate
>> population density. A way to gauge built-up density. A data source for
>> locating buildings in possible flood zones, or fire risk. Statistics:
>> as open data, queryable by APIs that are already used, in format
>> more-or-less common worldwide.
>>
>> Examples were given of rowhouse- or de-facto rowhouse-buildings where
>> a part is attached to the wrong building. This does not alter any of
>> the above examples. It's wrong, but is it substantially more wrong
>> than a blank subdivision, or one with only a few buildings mapped? Is
>> it better to have a null, or be off by 5%? The legal truth is in
>> property records, and we can't measure houses with a ruler, so OSM can
>> only be a 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Hi Yaro,

I just had a chance to look at the documentation on the source data and 
I wasn't able to find anything about 3D features or parts of buildings 
being mapped separately. Are you guessing here, or is there 
documentation on this? If so can you point us to it?


In any case, the big shapefiles from StatsCan don't provide enough 
information to reconstruct any 3D geometries, so I'd be inclined to 
remove these from the import unless they can be brought in from another 
source with better documentation / attribute tagging. (i.e. City of 
Toronto?)


Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it in 
Toronto and Kingston and I found it to be very good, consistent and 
precise. Time-wise it's somewhat current with 2016 ESRI imagery 
(sometimes ahead, sometimes slightly behind) and is well-aligned with 
it. It offers 3D features (when several buildings appear overlapped in 
the dataset) but you just need to be familiar with `building:part` tag 
to sort through it. I haven't looked at other provinces but in Ontario 
I really have no complaints about dataset quality whatsoever. Also I 
don't get Nate's "wildly unsimplified geometries" comment. IMO 
geometries are just perfectly detailed.



On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski > wrote:


Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so OSM can
only be a statistical source. And then there's the question of
verifiability - some of these buildings are connected to their
neighbour building inside. I've really struggled at distinguishing
what exactly is a "building" on Old Toronto avenues even with
street-side survey.

Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
and I'm sure many of you do as well. If we import, the question is:
are we making it better?

1. Do we want this data?
2. Is it generally of acceptable quality?
3. Is there a mechanism to spot and reject where data is
particularly bad?

Cheers,
Jarek, who should really get back to updating built-last-year
stuff at Fort York

On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall
mailto:kyle.nutt...@hotmail.ca>> wrote:
>
> The pilot project that took place in Ottawa for all these
building imports is what got me 

[Talk-ca] Place Tagging

[Danny McDonald]

My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
  Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

Any thoughts?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 114, Udgave 3

[Martin Hvidberg]

Stednavne i Grønland er et både vanskeligt og følsomt emne.

Der arbejdes på det i Grønland, af gode dygtigt folk i Oqaasileriffik og 
ditto hos Asiaq, så man skal være rigtigt meget sikker i sin sag for at 
second-guesse de officielle optegnelser.


Bl.a. har en stor del af navneregisteret for Grønland, på et tidspunkt, 
været konverteret til decimalgrader med få (kun 1 som jeg husker) 
decimal. Det har givet nogle uheldige og til tider stærkt misvisende 
placeringer - Nogle af disse data findes også i brug hos GEUS, selv om 
fejlen formodentligt oprindeligt stammer fra daværende KMS. Navne 
'forskydningen' har blandt andet medført at oplagte vand-navne som fx 
'sælbugten' ender på toppen af et fjeld, og tilsvarende. Men da navnene 
primært er på grønlandsk kan det være vanskeligt for 
ikke-grønlandsktalende at opdage sådanne smuttere. Alene derfor bør man 
være forsigtig.


Der er desuden flere sprog i spil. De fleste steder har et primært navn 
på Grønlandsk og et alternativt navn på et andet sprog. Det andet sprog 
kan være dansk, men det kan også ofte være engelsk! Der findes desuden 
forskellige dialekter af grønlandsk (eller i hvert fald forskellige 
stavemåder) Primært skelnes mellem Øst- og Vest-grønlandsk. Denne 
skelnen er forbundet med stor vigtighed for en grønlænder, og kan ikke 
overvurderes.


Nogle lokaliteter i Grønland har kun udenlandske navne, typisk opfundet 
af udenlandske hvalfangere, militærfolk eller forskere. Selv om disse 
som regel er lavet af nød, p.g.a. mangel på eksisterende navne, så er 
det altid upopulært - lige som vi ikke bryder os om at tyskerne kalde 
'Slesvig' for 'Schleswig'


Jeg anbefaler, kraftigt, at man skeler til de officielle betegnelser 
inden man kaster sig ud at navngive steder i Grønland, og at man altid 
søger Grønlandsk sproget assistance - Der er mange faldgruber, og det er 
et følsomt emne i Grønland.


vh. Martin (engang ansvarlig for de grønlandske stednavnesamlinger ved GST)


On 1/24/19 1:00 PM, talk-dk-requ...@openstreetmap.org wrote:

Send meddelelser der skal distribueres til Talk-dk til:
talk-dk@openstreetmap.org

Gå ind på:
https://lists.openstreetmap.org/listinfo/talk-dk
for at til- eller framelde dig listen via World Wide Web

Alternativt kan du sende en e-mail til
talk-dk-requ...@openstreetmap.org
med ordet 'help' i emnefeltet eller som indhold.

Du kan kontakte den (de) ansvarlige person(er) for listen på
talk-dk-ow...@openstreetmap.org

Når du svarer på e-mail til listen, bedes du venligst ændre
emnefeltet sådan at det er lidt mere beskrivende end bare "Re:
Indhold af Talk-dk sammendrag..."


Dagens emner:

1. Re:  Nordøstgrønland - kvalificeret hjælp søges
   (Jørgen Elgaard Larsen)
2. Nordøstgrønland - kvalificeret hjælp søges (Anders Hedelund)


--

Message: 1
Date: Wed, 23 Jan 2019 16:25:06 +0100
From: Jørgen Elgaard Larsen 
To: talk-dk@openstreetmap.org
Subject: Re: [Talk-dk]  Nordøstgrønland - kvalificeret hjælp søges
Message-ID: <2010a960-79de-c9f7-6389-2a9cb4126...@elgaard.net>
Content-Type: text/plain; charset=utf-8; format=flowed

Anders Hedelund skrev:

Så har jeg færdigredigeret hele baduljen til det sted, hvor jeg ikke
umiddelbart kan komme videre og der er brug for, at nogen ser på det.

Godt arbejde! Og fin dokumentation.

Har du diskuteret importen med de lokale? Jeg kan se, at mailinglisten
talk-gl tilsyneladende ikke længere findes, men du kan jo prøve at tage
fat i nogle af dem, der er nævnt på
https://wiki.openstreetmap.org/wiki/WikiProject_Greenland (selvom siden
ser lidt forladt ud).


Jeg har kigget lidt nærmere på dit regneark. Det ser overordnet godt ud,
men der er nogle mindre spørgsmål og issues.


Først og fremmest: Hvilken projektion er koordinaterne?
Jeg har prøvet at hente WFS fra GEUS, og den bruger tilsyneladende
EPSG:32627. Har du reprojiceret eller er dine koordinater stadig EPSG:32627?

For det andet: Er listen renset for ting, der allerede findes i OSM?
Ellers skal der laves et arbejde for at sortere dem fra.

Der er lidt rod i kolonnerne OSM1, OSM2 og OSM3. Det lader til, at du
primært bruger OSM1: key, OSM2: value, OSM3: key=value (Eksempelvis
"Dortes Kulmine").
Men f.x. "Fox Havn" har OSM1: "harbour=yes" og intet andet.
Og "Sandstensfjeldene" har OSM1: natural, OSM2: mountain_range, OSM3: range.


Så er der nogle lidt sære tags.
"Snemarken" natural=glacier, type=icecap.
Det burde være natural=glacier, glacier:type=icecap

"Nesodden" har natural=region, region=peninsula.
Jeg kan ikke finde dokumentation for natural=region.
Du bør i stedet tagge som enten natural=peninsula (proposed tag) eller
place=peninsula (tidligere de facto tagging).

"Finderup Land" har place=region,region=area.
place=region lader til at være lidt deprecated, og jeg kan ikke finde
dokumentation for region=area. Jeg er ikke sikker på, hvordan det er
korrekt at tagge, men jeg ville i hvert fald droppe region=area.

Re: [talk-cz] Hlavni mesta - capital=yes

[Dalibor Jelínek]

V tom případě to blbě je.


Dalibor

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Thursday, January 24, 2019 2:01 PM
To: OpenStreetMap Czech Republic 
Subject: Re: [talk-cz] Hlavni mesta - capital=yes

 

Jenže relace Praha není otagováná jako multipolygon ( 
https://www.openstreetmap.org/relation/439840 ).

 

Marián

 

-- Původní e-mail --
Od: Dalibor Jelínek mailto:dali...@dalibor.cz> >
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org> >
Datum: 24. 1. 2019 13:38:40
Předmět: Re: [talk-cz] Hlavni mesta - capital=yes 



Neřekl bych. Relace multipolygon se na wiki bere jako plocha. 

Dalibor 

 

 

 

Sent from my Samsung Galaxy smartphone.

 

 Original message 

From: Marián Kyral mailto:mky...@email.cz> > 

Date: 24/01/2019 13:15 (GMT+01:00) 

To: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org> > 

Subject: Re: [talk-cz] Hlavni mesta - capital=yes 

 

Podle wiki, by capital=yes mělo být buď na bodech nebo na plochách: 
https://wiki.openstreetmap.org/wiki/Key:capital

Takže pokud je tento tag na relaci, tak je to špatně :-D

 

Marián

 

-- Původní e-mail --
Od: majka mailto:majka.zem+t...@gmail.com> >
Komu: Jan Cibulka mailto:ho...@datastory.cz> >, 
OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org> >
Datum: 24. 1. 2019 12:17:21
Předmět: Re: [talk-cz] Hlavni mesta - capital=yes 



Ty chybějící capital=yes jsou na bodech. Takže podle mě to chce vzít rekurzí, 
tedy najít ty body  , a pak najít hranici města 
okolo nich.

Majka

On Thu, 24 Jan 2019 at 10:34, Jan Cibulka ho...@datastory.cz 
  wrote:

Zdravím vespolek,

tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně identifikovat 
hranice hlavního města? Jde mi to, že pokud se snažim vyexportovat hranice 
všech evropskejch hlavních měst [1] přes relation["capital"="yes"], tak dostanu 
např. Řím, Varšavu nebo Paříž, nikoli ale Prahu a Londýn (a další).

___
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

[Diversity-talk] Fwd: Women Connect project launch!

[Rory McCann]

Might be interesting to some

On 17/01/2019 16:02, Rebecca Firth wrote:
> [announcing new hot staff member]
>
This month we're also kicking off our Women Connect project! Whilst 
gender equality has been a focus for HOT over many years, this is our 
first explicit program working to include women and girls in mapping 
gendered issues which affect them in their local communities. More on 
the program here: 
https://www.hotosm.org/projects/women-connect-number-letgirlsmap-growing-female-open-data-leaders-across-5-continents/


Thanks, and please get in touch with any questions,

Rebecca

--
*Rebecca Firth*
Director, Community & Partnerships
rebecca.firth-r9u8hhsi424dnm+yrof...@public.gmane.org 


@RebeccaFirthy

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | 
facebook  | donate 



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [talk-cz] Hromadná editace/úkol pro všechny? Bylo: Seznam vodních ploch se špatnou kategoriií

[majka]

On Thu, 24 Jan 2019 at 13:18, Pavel Machek  wrote:

Ja porad nechapu co presne chcete menit.
>
> Co si pamatuju, tak rybnik nema mit natural=*, protoze neni tak uplne
> prirodni, postavil ho clovek.
>
To ale (podle wiki
)
není tak úplně pravda, a naprosto běžně
 se používá pro i
člověkem postavené rybníky a přehrady.
V landuse je to považované za zastaralé značení, a doporučované
 je jako natural=water
+ kombinace.

Wiki je v tomhle zmatečná, každá stránka (i každá jazyková verze) píše něco
trochu jiného. Na tom, že je tohle značení považované za zastaralé (i když
není výslovně zrušené) se ale shodují všechny.
Ta debata o zastaralosti probíhala v červnu 2013 - kdy se to znovu
“oživilo”, tedy kdy se na wiki revertovalo  deprecated  - a už tenkrát
víceméně padla shoda v tom, že samotná “hladina” by měla mít značku water.
Z té debaty vyplynula definice landuse=reservoir spíš jako například
ochranné pásmo vodního zdroje - tj. ta část “na suchu”, a debatovalo se o
tom, jestli/jak tuhle část značit jinak.

Co se dívám na taginfo
,
řekla bych že většina značení jako landuse=reservoir budou starší importy.
Zrovna ten náš dibavod v tom hraje poměrně podstatnou roli.

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

Re: [talk-cz] Hlavni mesta - capital=yes

[Marián Kyral]

Jenže relace Praha není otagováná jako multipolygon ( https://www.
openstreetmap.org/relation/439840 ).





Marián



-- Původní e-mail --
Od: Dalibor Jelínek 
Komu: OpenStreetMap Czech Republic 
Datum: 24. 1. 2019 13:38:40
Předmět: Re: [talk-cz] Hlavni mesta - capital=yes
"
Neřekl bych. Relace multipolygon se na wiki bere jako plocha. 

Dalibor 











Sent from my Samsung Galaxy smartphone.






 Original message 

From: Marián Kyral 

Date: 24/01/2019 13:15 (GMT+01:00)

To: OpenStreetMap Czech Republic 

Subject: Re: [talk-cz] Hlavni mesta - capital=yes





Podle wiki, by capital=yes mělo být buď na bodech nebo na plochách: https://
wiki.openstreetmap.org/wiki/Key:capital

Takže pokud je tento tag na relaci, tak je to špatně :-D




Marián



-- Původní e-mail --
Od: majka 
Komu: Jan Cibulka , OpenStreetMap Czech Republic 
Datum: 24. 1. 2019 12:17:21
Předmět: Re: [talk-cz] Hlavni mesta - capital=yes
"


Ty chybějící capital=yes jsou na bodech. Takže podle mě to chce vzít
rekurzí, tedy najít ty body(http://overpass-turbo.eu/s/jxO), a pak najít
hranici města okolo nich.

Majka

On Thu, 24 Jan 2019 at 10:34, Jan Cibulka ho...@datastory.cz
(http://mailto:ho...@datastory.cz) wrote:





"

Zdravím vespolek,

tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně
identifikovat hranice hlavního města? Jde mi to, že pokud se snažim
vyexportovat hranice všech evropskejch hlavních měst [1] přes relation[
"capital"="yes"], tak dostanu např. Řím, Varšavu nebo Paříž, nikoli ale
Prahu a Londýn (a další).


"








___
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-GB] OS National Grid References

[Brian Prangle]

Thanks for your knowledgeable replies which reassure me that grid refs are
not copyright, but the 1995 court case is still perplexing. My source was a
news item from the Guardian and I can't find any accessible online source
which has the legal argument and details of the case. Does anyone know any
more about this case? Perhaps I should ask OS.

Regards

Brian

On Tue, 22 Jan 2019 at 23:53, SK53  wrote:

> As virtually every biological recording scheme has used National Grid
> references extensively since the early 1960s , and OSGB have not (yet) sued
> me for my user name, I think you can take that this is pretty much a dead
> letter.
>
> I can also cite Constable walking guides from the 1970s.
>
> Any attempt by OSGB to enforce copyright would undoubtedly be
> self-defeating, so I cant see them doing it.
>
> Jerry
>
> On Tue, 22 Jan 2019 at 16:21, Brian Prangle  wrote:
>
>> Are these covered by copyright? I've found conflicting opinions:
>>
>> out of copyright in 1986 - since it was 50 years since the introduction
>> of the NG in 1936
>>
>> and
>>
>> "current case law supports this ownership, given in Ordnance Survey vs
>> Younger and others (Ch 10 April 1995), in which Sir Jeremy Vinelott,
>> sitting as a Judge of the High Court, ruled that "OS copyright material
>> includes the National Grid" and that "the OS retain the right to refuse to
>> allow ... [someone] ... to use the National Grid", a right taken up in that
>> case. "
>>
>> Can anyone shed any light on this?
>>
>> regards
>>
>> Brian
>> ___
>> 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] Hlavni mesta - capital=yes

[Dalibor Jelínek]

Neřekl bych. Relace multipolygon se na wiki bere jako plocha. Dalibor 


Sent from my Samsung Galaxy smartphone.
 Original message From: Marián Kyral  Date: 
24/01/2019  13:15  (GMT+01:00) To: OpenStreetMap Czech Republic 
 Subject: Re: [talk-cz] Hlavni mesta - capital=yes 
Podle wiki, by capital=yes mělo být buď na bodech nebo na plochách: 
https://wiki.openstreetmap.org/wiki/Key:capitalTakže pokud je tento tag na 
relaci, tak je to špatně :-D
Marián

-- Původní e-mail --

Od: majka 

Komu: Jan Cibulka , OpenStreetMap Czech Republic 


Datum: 24. 1. 2019 12:17:21

Předmět: Re: [talk-cz] Hlavni mesta - capital=yes

Ty chybějící capital=yes jsou na bodech. Takže podle mě to chce vzít rekurzí, 
tedy najít ty body, a pak najít hranici města okolo nich.Majka
On Thu, 24 Jan 2019 at 10:34, Jan Cibulka ho...@datastory.cz wrote:

Zdravím vespolek,
tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně
  identifikovat hranice hlavního města? Jde mi to, že pokud se
  snažim vyexportovat hranice všech evropskejch hlavních měst [1]
  přes relation["capital"="yes"], tak dostanu např. Řím, Varšavu
  nebo Paříž, nikoli ale Prahu a Londýn (a další).



___
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] Hromadná editace/úkol pro všechny? Bylo: Seznam vodních ploch se špatnou kategoriií

[Pavel Machek]

Ahoj!

> K téhle záležitosti - nebylo by vhodné udělat hromadnou opravu, případně
> nějakou akci přes task manager/poi importer?
> 
> Možnosti:
> 
>1. Tam, kde máme jak landuse=reservoir (vycházející z importu dibavod),
>tak i natural=water, water=[pond,lake], jen vymazat landuse=reservoir.
>2. Vyfiltrovat ty rybníky dotazem viz předchozí maily
>(landuse=reservoir, má dibavod:id, má jméno) a jednotlivě projít
>3. Totéž jako 2., ale pro všechny landuse=reservoir z dibavodu (tj. i
>nepojmenované) a všude opravit/doplnit značení.
> 
> Ad 1: pokud se shodneme, klidně udělám sama, vč. prohnání přes
> import list

Ja porad nechapu co presne chcete menit.

Co si pamatuju, tak rybnik nema mit natural=*, protoze neni tak uplne
prirodni, postavil ho clovek.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [talk-cz] Hlavni mesta - capital=yes

[Marián Kyral]

Podle wiki, by capital=yes mělo být buď na bodech nebo na plochách: https://
wiki.openstreetmap.org/wiki/Key:capital

Takže pokud je tento tag na relaci, tak je to špatně :-D




Marián



-- Původní e-mail --
Od: majka 
Komu: Jan Cibulka , OpenStreetMap Czech Republic 
Datum: 24. 1. 2019 12:17:21
Předmět: Re: [talk-cz] Hlavni mesta - capital=yes
"


Ty chybějící capital=yes jsou na bodech. Takže podle mě to chce vzít
rekurzí, tedy najít ty body(http://overpass-turbo.eu/s/jxO), a pak najít
hranici města okolo nich.

Majka

On Thu, 24 Jan 2019 at 10:34, Jan Cibulka ho...@datastory.cz
(http://mailto:ho...@datastory.cz) wrote:





"

Zdravím vespolek,

tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně
identifikovat hranice hlavního města? Jde mi to, že pokud se snažim
vyexportovat hranice všech evropskejch hlavních měst [1] přes relation[
"capital"="yes"], tak dostanu např. Řím, Varšavu nebo Paříž, nikoli ale
Prahu a Londýn (a další).


"








___
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] pronto soccorso ospedali italiani

[EneaSuper]

Ottimo lavoro Aury, attendo con ansia la pubblicazione 



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [talk-cz] Hlavni mesta - capital=yes

[majka]

Ty chybějící capital=yes jsou na bodech. Takže podle mě to chce vzít
rekurzí, tedy najít ty body , a pak najít
hranici města okolo nich.

Majka

On Thu, 24 Jan 2019 at 10:34, Jan Cibulka ho...@datastory.cz
 wrote:

Zdravím vespolek,
>
> tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně
> identifikovat hranice hlavního města? Jde mi to, že pokud se snažim
> vyexportovat hranice všech evropskejch hlavních měst [1] přes
> relation["capital"="yes"], tak dostanu např. Řím, Varšavu nebo Paříž,
> nikoli ale Prahu a Londýn (a další).
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Hlavni mesta - capital=yes

[Jan Cibulka]

Zdravím vespolek,

tušíte, zda je možný (pro účel exportu přes overpass) jednoznačně identifikovat 
hranice hlavního města? Jde mi to, že pokud se snažim vyexportovat hranice 
všech evropskejch hlavních měst [1] přes relation["capital"="yes"], tak dostanu 
např. Řím, Varšavu nebo Paříž, nikoli ale Prahu a Londýn (a další).

Je nějakej důvod, proč třeba hranice Prahy capital=yes nemají?

Dík za všechny případný tipy.

[1] https://overpass-turbo.eu/s/FuH

--
S pozdravem

Jan Cibulka
tel.: +420 776 307 158
datastory.cz___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell

[Volker Schmidt]

Das ist ein langes Thema, mit dem auch ich mich rumschlage hier in Italien.
Ich bastele schon eine Weile an einer Bicycle Wiki-Seite fuer Italien.
Im Radbereich ist Europa noch fragmentierter als beim KFZ Verkehr. Hinzu
kommt hier, dass die Rechtsgrundlage konfus ist und daher einfache Dinge
wie bicycle=yes in vielen Faellen unklar sind.

Keep me posted, falls du was fur DE schreiben willst.

Volker




On Wed, 23 Jan 2019 at 18:49, Florian Lohoff  wrote:

>
> Moin,
> ich tue mir glaube ich wie viele Mapper mit dem Thema
> Radverkehrsinfrastruktur extrem schwer. Die Matrix mit
> "An der Straße", "Separat", "Benutzungspflichtig", "Radfahrstreifen",
> "Schutzstreifen", "Benutzbarer Mehrzweckstreifen", "Richtungsgebunden",
> "path vs cycleway", "Linksseitig - Radfahrer frei" etc ist einfach
> gigantisch.
>
> Ich bin jetzt hier drüber gestolpert:
>
> https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode
>
> Und habe da eine Verständnisfrage:
>
> Wenn ich das Modell richtig verstehe dann habe ich auf einer
> Straße die die tags für den Radweg beinhaltet
>
> cycleway:left=track
> cycleway=left
>
> D.h. ich habe beides. Korrekt verstanden? Das habe ich meinem tag
> Fehlerfinder bisher IIRC anders drin.
>
> Dann habe ich eine Frage zum Thema Schutzstreifen vs. Radfahrstreifen.
> Hier sagt das Modell das ein angeordneter Radfahrstreifen ein
> bicycle=designated bekommt. Ein Schutzstreifen bekommt ein bicycle=yes
> (Beide haben cycleway:*=lane.)
>
> D.h. ich habe bei Schutz-/Radfahrstreifen jetzt diese Kombinationen:
>
> Angeordneter Radfahrstreifen:
>
> cycleway=left
> cycleway:left=lane
> cycleway:left:bicycle=designated
>
> Schutzstreifen
>
> cycleway=left
> cycleway:left=lane
> cycleway:left:bicycle=yes
>
> Nicht angeordneter Radfahrstreifen:
>
> cycleway=left
> cycleway:left=lane
>
> Korrekt?
>
> Ich finde das ganze Thema Radinfrastruktur trotz Fahrradaffinität
> einfach nur ultrakompliziert. Und das Tagging in weiten teilen
> von OSM (Zumindest in Deutschland) spiegelt das wieder. Es wird
> irgendwas, irgendwie gemapped damit das in der Karte wie
> ein Radweg aussieht. Dann finden sich da bicycle=official oder
> designated oder yes und in wildesten kombinationen. Mal ist
> es separat gemapped mal an der Straße. Dann fehlen auf den
> Separaten wegen die oneways (Völlig unüblich) etc
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> 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