Re: [Talk-it] One feature, one element - scuole

[Cascafico Giovanni]

> On 3. Feb 2019, at 19:45, Lorenzo Mastrogiacomi 
wrote:

> La cosa migliore secondo me sarebbe cercare di capire qual'è l'area di
competenza di ciascuna scuola e tracciare quindi le due aree parzialmente
sovrapposte.

Si, questi casi si possono risolvere senza ambiguità.

> Se proprio le due scuole condividono la stessa identica area si possono
usare le relazioni multipoligono per creare più elementi area con lo stesso
unico poligono esterno.

Ma il multipoligono: credo serva a risolvere problemi geometrici come i
buchi. Come nella wiki a me piacerebbe usare la relazione "site".

 > Immagino una poligono senza tag che sarà poi utilizzato in due
relazioni, una per ogni scuola e con i propri tag.
Sarebbe logico inserire in due relazioni "site" con i tag specifici di
ciascuna scuola, però un poligono senza tag come verrebbe interpretato in
OSM?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] One feature, one element - scuole

[Simone Saviolo]

Il giorno dom 3 feb 2019 alle ore 23:23 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> > On 3. Feb 2019, at 19:45, Lorenzo Mastrogiacomi 
> wrote:
> >
> > La cosa migliore secondo me sarebbe cercare di capire qual'è l'area di
> > competenza di ciascuna scuola e tracciare quindi le due aree
> > parzialmente sovrapposte.
> >
> > Se proprio le due scuole condividono la stessa identica area si possono
> > usare le relazioni multipoligono per creare più elementi area con lo
> > stesso unico poligono esterno.
> > Immagino una poligono senza tag che sarà poi utilizzato in due
> > relazioni, una per ogni scuola e con i propri tag.
>
> +1, un amenity=school per ogni scuola (con gli altri tag come name, ecc.),
> lo farei anch’io così, idealmente come aree.
>

Sì, idealmente come aree. Però attenzione: di anno in anno (o a volte anche
più spesso) potrebbero riassegnare qualche aula da una scuola a un'altra;
oppure potrebbe esserci una palestra condivisa tra tutte le scuole; o
locali di servizi (mensa, infermieria, aule professori).

Sicuramente, disegnerei un'area per rappresentare l'edificio, con
building=*. Dentro a quello metterei *almeno* dei nodi con amenity=school e
tutto il resto delle informazioni; se il mappatore ha voglia di mappare i
dettagli, disegni le aree delle scuole.

Ciao,

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

Re: [Talk-it] United Nations Maps Project

[Alessandro P. via Talk-it]

  
  
Se qualcuno, magari aspettando che il Tasking Manager italiano torni
sù, vuole dare una mano eccovi il task

https://tasks.hotosm.org/project/5701


  
 #5701 - UN Maps: Roads
  around Wanlaweyn, Somalia 
  


  The Department of Peacekeeping Operations (DPKO) of the United
Nations (UN) provides support to humanitarian, security and
logistics activities in several areas in the World. One of these
countries is Somalia where the UN established a mission, UNSOS,
in November 2015 to provide critical support to the national
institutions and other political partners to make them more
effective in defeating enemies of peace and in creating the
much-needed space for political reconciliation, state formation
and extension of government authority in Somalia.
  The Objective of this mapping project is to enrich the
topographic data in Somalia with the aim to assist the UN
mission in the country in their field endeavors, such as peace
and security, navigation, and logistics by providing its
peacekeepers with topographic maps that will help them in their
tactical and operational activities.
  Your participation is important to achieve peace and stability
in Somalia!!!



Alessandro

  


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

Re: [talk-cz] [Talk-cz] opět Prušánky

[Tom Ka]

Zdravim pane Janecek,

nevidel jsem zadnou vasi reakci, pokud neodebirate mail list talk-cz,
lze se na reakce podivat zde:
https://lists.openstreetmap.org/pipermail/talk-cz/2019-February/thread.html

resp. tyto dve vlakna
https://lists.openstreetmap.org/pipermail/talk-cz/2019-February/020775.html
https://lists.openstreetmap.org/pipermail/talk-cz/2019-February/020780.html

Jak vidite, je tam nekolik navrhu, co zlepsit, urcite se z toho neco da pouzit.

Hezky den tom.k

pá 1. 2. 2019 v 16:39 odesílatel Miroslav Suchy  napsal:
>
> Dne 01. 02. 19 v 10:40 Jan Macura napsal(a):
> > On Fri, 1 Feb 2019 at 08:36, Pavel Janeček  > > wrote:
> >
> > Také úplně nechápu proces verifikace. Měl jsem za to, že se lze do 
> > projektu zapojit svobodně a "někdo" mou práci
> > pustí příp. odmítne.
> >
> >
> > Žádný "někdo" není. Provedené změny se projeví okamžitě, jakákoliv kontrola 
> > editací je možná až zpětně a spíše náhodně,
> > než systematicky.
>
> Přesně. Není nikdo kdo by kontroloval "všechno". Občas někdo narazí na něco 
> podezřelého a pak se trochu detailně někdo
> podívá na tu oblast nebo na toho uživatele.
>
> Není nutné kontrolovat jednotilvé žáky během hodiny. Klidně až po hodině nebo 
> po týdnu kouknout na jejich historii.
> Např. moje historie je zde:
>
> https://www.openstreetmap.org/user/Miroslav Suchý/history
>
> Takže pro uživatele FOO by to bylo
>
> https://www.openstreetmap.org/user/FOO/history
>
> Miroslav
>
> ___
> 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

[Aury88]

dieterdreist wrote
> sent from a phone
> 
>> On 3. Feb 2019, at 09:56, Aury88 

> spacedriver88@

>  wrote:
>> 
>> Se siete d'accordo su questa metodologia, metto il mio account  e poi chi
>> vorrà potrà aggiungere il proprio link.
> 
> 
> generalmente le pagine che descrivono i features, sono definiti in
> inglese, e le traduzioni dovrebbero essere appunto questo: traduzioni.
> Quindi la pagina italiana di amenity=hospital dovrebbe essere una
> traduzione della pagina inglese, e se si intende aggiungere informazioni
> sarebbe la cosa migliore farlo per prima in inglese.
> 
> Non è una critica dei contenuti che vuoi mettere, ma è come penso dovrebbe
> funzionare il wiki. 
> 
> Ciao, Martin 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

non sono d'accordo. se fosse come dici tu non servirebbe avere le voci nelle
varie lingue ma basterebbe la possibilità di effettuare la traduzione
online. ci sono troppi casi specifici locali, o utilizzi errati locali per i
quali vale la pena sottolineare, solo nelle singole lingue, cosa fare o non
fare. inoltre, come hai modo di vedere da questa discussione, le modifiche
sono state discusse, proposte, testate ed infine trasferite sulla voce wiki. 
avessi dovuto farlo anche per la wiki "internazionale", ipotizzando che
fossi in grado di fare tutto questo in maniera corretta in un altra lingua,
per un tema del genere saremmo ancora  a parlare delle modifiche per i
futuri anni mentre in italia, aspettando che a livello internazionali si
decida di integrare nella voce accenni a altri* tag già esistenti ed
approvati*, si continuerebbe a vedere applicato male e contrario allo stile
internazionale il tag amenity=hospitalanche a causa di una voce in
italiano che asseriva "Se più edifici adibiti ad ospedale sono presenti in
un'unica grande area considerate l'eventualità di combinare queste
informazioni in una relazione al posto di taggare ogni singolo edificio come
tale"[cit] questa si una invenzione italiana e addirittura il cui effetto è
quello di vedere applicato il tag sui singoli edifici; contrario quindi a
quanto asserito alla wiki inglesequesto non va bene, non imho integrare
una voce con elementi secondari e che fanno riferimento a std approvato a
liv. internazionale

solo un appunto Martin...è da due settimane che è possibile vedere la sandox
e discutere delle modifiche, due settimane in cui nessuno ha avuto da
obbiettare all'aggiunta di elementi in più rispetto la voce in inglese
nonostante l'ampia discussione qui e la diffusione della notizia sul canale
telegram, non capisco quindi perchè hai aspettato che pubblicassi la
modifica prima di intervenire. non era meglio farlo prima che fosse fatto il
danno? 



-
Ciao,
Aury
--
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

[OSM-ja] 3/2 オープンストリートマップ関西 大集結

[yasunari yamashita]

山下です。
皆さんこんにちわ。

来る 3/2 （土）の International Open Data Day 2019 にあわせ
オープンストリートマップ関西　大集結
と題して
各地のオープンストリートマップ勢が集結するイベントを開催します。
https://openstreetmap-kansai.connpass.com/event/118851/

各地の／各団体の／各参加者の活動報告をいただき、
横のつながりを深め、
オープンストリートマップの発展を狙います。
もちろん関西以外からの参加も歓迎します。

皆さまの参加をお待ちしています！
-- 
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] 日本独自の地図

[大和田健一]

大和田です。
日本独自の地図と世界共通の違いはなんですか。
パッと見では、地名が日本語（英語）になっているようだ。

地図タイルについて調べていたら、飯田さんの記事が見つかったわ。

OpenStreetMapの各種タイル指定
https://qiita.com/nyampire/items/fbe359a2c9ccf0116787

OpenStreetMap のタイルサーバー立ててみました
https://blog.mori-soft.com/entry/2017/12/28/104556

大和田健一 
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-ca] Some feedback on import quality in Toronto

[OSM Volunteer stevea]

It is an honor to participate in this good growth.  May good 
(province-at-a-time building) data enter OSM at the hands of skilled OSM 
editors who have good instructions on "how" (the Import Plan can go that 
distance, please finish it) as their skills of good editing OSM data push the 
import ahead.  Speaking for myself, I like what I see here:  a community 
speaking amongst itself/ourselves.

Should "tall enough to ride the ride" volunteers "step right up" I think the 
current red flags can go to yellow, then green.  Nate, Yaro, Pierre, Blake, 
Nate, John, Danny, so many others here unnamed have shown leadership.  Many 
Canadians seem on the road to "how" and "talk amongst yourselves."  Good is not 
the enemy.  Good are good enough as they are included with "how."  Thumbs up 
from here ahead.  I keep trying to be outta here.

Et, voilá.

SteveA
> 


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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Danny McDonald]

I largely agree with Yaro, but will say
1) It is possible to square almost square angles with JOSM - it has an
informational warning in validation, and automatically squares the angle by
slightly moving the offending node.  This fix doesn't ruin the geometry of
the building, as pressing Q so often does.  Unfortunately, it also leads to
other angles in the building not being square.
3) I'm fine with importing smaller buildings as well (they don't seem to be
in the source data in Toronto, they are for some of the other data sets).
I believe they were excluded because of their relatively low
importance/permanence.

I would also like to know how the Toronto building footprints were
produced.  Does anyone know?
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

I'm not hearing we have a clear consensus on modifying the shape of
buildings with scripts and the Q button.

My own personal view is it could introduce errors and unless it is very
obviously wrong when it should get picked up by the importing mapper it
should be left as is.

Cheerio John

On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:

> I'm hearing we keep the single import project as such.
>
> I'm hearing that we should preprocess the data first splitting out
> outlines that meet Pierre's right angle checks.  This data can just be
> imported using the current processes.
>
> I'm hearing we should then run the correcting scripts and extract the
> corrected buildings.  This becomes the second stage.  This data should be
> imported separately to the first since it needs to be more closely
> inspected in case the script has caused some deformation.
>
> At the moment I'm not sure if the two scripts above exist.
>
> I'm hearing what is left becomes the third stage which needs to be sorted
> out manually before being made available for import.  Again I see this as a
> separate task since the outlines will have been modified from the original.
>
> Note to James is the above practical?  Do we have the resources to do it?
> Please do not do anything until we have an agreement to proceed.
>
> I'm hearing the existing imported building outlines will be subject to an
> overpass to pick out those building outlines that are not square.
>
> Then the "a miracle occurs" box on the project plan gets these into a JOSM
> todo list and mappers manually sort them out.  I'm not certain how this
> will happen.  I suspect if the overpass query is small enough and the
> buildings are loaded up from an off line source this might work.
>
> To come back to Toronto my feeling is this is best left to the local
> mappers in Toronto to decide how to proceed.  There is/was room for a local
> coordinator in the project plan.  Nate's expectations are different to mine
> and I think it makes sense for the local mappers to decide what they would
> like to do together with Nate and a Toronto mapper set themselves up to
> coordinate in Toronto.  The speed at which the buildings were added has
> been raised as a concern.  I'm unable to think of a way to address this
> other than a "please take it slowly" added to the instructions.
>
> Again this option is available to any other areas who would like to use
> this method.
>
> I feel for Quebec the best thing to do is hold back until we have an
> agreement for the rest of the country since there are Quebec mappers who
> are not following this thread on talk-ca and to be honest we do seem to be
> evolving on a hourly basis so waiting until the dust settles might well be
> sensible.
>
> Am I missing something apart from my sanity?
>
> Thanks John
>
> On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:
>
>> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
>> qu'ensuite il sera beaucoup plus simple d'importer les données déja
>> corrigées. Sinon une variable pour distinguer les deux et risque de
>> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
>> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
>> données corrigées.
>>
>> L'importation des données orthogonales devrait être grandement facilitée.
>> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
>> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
>> s'agirait davantage de valider avec l'imagerie et de faire la conflation
>> avec les données existantes.
>>
>> Pour l'importation des données irrégulières, il faudrait oui valider /
>> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
>> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
>> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
>> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
>> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
>> greffon ToDo est très utilie pour réviser successivement des données et
>> s'assurer de toutes les réviser.
>>
>> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment
>> ci-dessous avec beaucoup d'angles se rapprochant de 90 degrés mais avec une
>> variance plus grande que +-5 degrés. Pour détecter davantage de bâiments
>> quasi-orthogonaux, il serait possible de tenir compte de cette situation
>> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
>> tester cette option et voir si cela permettrait de détecter un grand nombre
>> de cas.
>> angles entre 82.6 et 94.5 degrés
>>
>> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
>> https://www.openstreetmap.org/way/479048070
>>
>> Pierre
>>
>>
>> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
>> jwhelan0...@gmail.com> a écrit :
>>
>>
>> I accept the nicest way is to check the data beforehand.  

Re: [Talk-ca] Some feedback on import quality in Toronto

[Yaro Shkvorets]

Having reviewed the changeset, here are my 2 cents. OsmCha link for
reference: https://osmcha.mapbox.com/changesets/66881357/

1) IMO squaring is not needed in most of those cases.
- You can see difference between square and non-square ONLY at high zoom
level. And even then, it's not visible to the naked eye. We are talking
about inches here.
- Sometimes squaring is plain wrong to be applied here. Even though you
paid very close attention you managed to square a couple of non-square
buildings. Like this facade is not supposed to be square for example:
https://i.imgur.com/H10360K.png I might be OK with squaring almost-square
angles if there is a simple plugin for that. The way you propose to do it,
by going building-by-building and pressing Q is completely unsustainable
and sometimes makes things bad.
- Another thing, this particular neighbourhood is pretty dense and mature
and therefore has mostly square buildings. I can only imagine how bad it
would become if you ask people to square things in newer developments where
buildings often come in irregular shapes.
- Like mentioned above, many successful import didn't require squaring. In
this Texas one, 100% of buildings are not perfectly square:
https://www.openstreetmap.org/#map=19/32.97102/-96.78231


2) Simplification is good to have, sure. Obviously standard Shift-Y in JOSM
is a no-starter. If we can find a good way to simplify ways without losing
original geometry and causing overlapping issues we should do it. But even
then, reducing 500MB province extract to 499MB should not be a hill to die
on.

3) Manually mapping all the sheds and garages is completely unsustainable.
Having seen over the last couple of years how much real interest there is
in doing actual work importing buildings in Canada (almost zero) adding
this requirement will undoubtedly kill the project. Sure you will
meticulously map your own neighbourhood, but who will map thousands of
other places with the same attention to details? Also, you did rather poor
job at classifying buildings you add, tagging them all with building=yes.
Properly classifying secondary buildings like sheds and garages in a
project like this is pretty important IMO. I agree with John, we should
leave sheds to local mappers to trace manually.

To sum up, yes we can do better. But this is the perfect example when
"better" is the enemy of "good".

On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> 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
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

I dislike sounding simply "like a cheerleader," here however, I am deeply 
encouraged by what I see as substantial progress.  This sort of discussion 
bodes very well for the future of the import.  Keep up the good work!

SteveA

On Feb 3, 2019, at 3:26 PM, john whelan  wrote:
> I'm hearing we keep the single import project as such.

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

Re: [Talk-ca] Building Import update

[john whelan]

I'm hearing we keep the single import project as such.

I'm hearing that we should preprocess the data first splitting out outlines
that meet Pierre's right angle checks.  This data can just be imported
using the current processes.

I'm hearing we should then run the correcting scripts and extract the
corrected buildings.  This becomes the second stage.  This data should be
imported separately to the first since it needs to be more closely
inspected in case the script has caused some deformation.

At the moment I'm not sure if the two scripts above exist.

I'm hearing what is left becomes the third stage which needs to be sorted
out manually before being made available for import.  Again I see this as a
separate task since the outlines will have been modified from the original.

Note to James is the above practical?  Do we have the resources to do it?
Please do not do anything until we have an agreement to proceed.

I'm hearing the existing imported building outlines will be subject to an
overpass to pick out those building outlines that are not square.

Then the "a miracle occurs" box on the project plan gets these into a JOSM
todo list and mappers manually sort them out.  I'm not certain how this
will happen.  I suspect if the overpass query is small enough and the
buildings are loaded up from an off line source this might work.

To come back to Toronto my feeling is this is best left to the local
mappers in Toronto to decide how to proceed.  There is/was room for a local
coordinator in the project plan.  Nate's expectations are different to mine
and I think it makes sense for the local mappers to decide what they would
like to do together with Nate and a Toronto mapper set themselves up to
coordinate in Toronto.  The speed at which the buildings were added has
been raised as a concern.  I'm unable to think of a way to address this
other than a "please take it slowly" added to the instructions.

Again this option is available to any other areas who would like to use
this method.

I feel for Quebec the best thing to do is hold back until we have an
agreement for the rest of the country since there are Quebec mappers who
are not following this thread on talk-ca and to be honest we do seem to be
evolving on a hourly basis so waiting until the dust settles might well be
sensible.

Am I missing something apart from my sanity?

Thanks John

On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:

> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
> qu'ensuite il sera beaucoup plus simple d'importer les données déja
> corrigées. Sinon une variable pour distinguer les deux et risque de
> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
> données corrigées.
>
> L'importation des données orthogonales devrait être grandement facilitée.
> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
> s'agirait davantage de valider avec l'imagerie et de faire la conflation
> avec les données existantes.
>
> Pour l'importation des données irrégulières, il faudrait oui valider /
> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
> greffon ToDo est très utilie pour réviser successivement des données et
> s'assurer de toutes les réviser.
>
> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous
> avec beaucoup d'angles se rapprochant de 90 degrés mais avec une variance
> plus grande que +-5 degrés. Pour détecter davantage de bâiments
> quasi-orthogonaux, il serait possible de tenir compte de cette situation
> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
> tester cette option et voir si cela permettrait de détecter un grand nombre
> de cas.
> angles entre 82.6 et 94.5 degrés
>
> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
> https://www.openstreetmap.org/way/479048070
>
> Pierre
>
>
> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I accept the nicest way is to check the data beforehand.  Scripting it is
> fairly simple.  Are you suggesting a two stage process of take the data and
> run the script first then task manager the data to be imported to manually
> correct the data?  My eyesight isn't good enough to pick out none right
> angled corners so is there some way someone can come up with to feed them
> into a JOSM todo list?
>
> However we have a fairly large number of building outlines that have
> already been imported.  The issue here is different as 

Re: [Talk-it] One feature, one element - scuole

[Martin Koppenhoefer]

sent from a phone

> On 3. Feb 2019, at 19:45, Lorenzo Mastrogiacomi  wrote:
> 
> La cosa migliore secondo me sarebbe cercare di capire qual'è l'area di
> competenza di ciascuna scuola e tracciare quindi le due aree
> parzialmente sovrapposte.
> 
> Se proprio le due scuole condividono la stessa identica area si possono
> usare le relazioni multipoligono per creare più elementi area con lo
> stesso unico poligono esterno.
> Immagino una poligono senza tag che sarà poi utilizzato in due
> relazioni, una per ogni scuola e con i propri tag.


+1, un amenity=school per ogni scuola (con gli altri tag come name, ecc.), lo 
farei anch’io così, idealmente come aree.

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes. 

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce cas on retrouve des angles qui 
s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement 
facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la 
touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un 
angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le 
greffon ToDo est très utilie pour réviser successivement des données et 
s'assurer de toutes les réviser.

A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous avec 
beaucoup d'angles se rapprochant de 90 degrés mais avec une variance plus 
grande que +-5 degrés. Pour détecter davantage de bâiments quasi-orthogonaux, 
il serait possible de tenir compte de cette situation uniquement pour angles à 
90 avec critère tolérance +-10 degrés. Je vais tester cette option et voir si 
cela permettrait de détecter un grand nombre de cas.angles entre 82.6 et 94.5 
degrés
{82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
https://www.openstreetmap.org/way/479048070
Pierre 
 

Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan 
 a écrit :  
 
 I accept the nicest way is to check the data beforehand.  Scripting it is 
fairly simple.  Are you suggesting a two stage process of take the data and run 
the script first then task manager the data to be imported to manually correct 
the data?  My eyesight isn't good enough to pick out none right angled corners 
so is there some way someone can come up with to feed them into a JOSM todo 
list?

However we have a fairly large number of building outlines that have already 
been imported.  The issue here is different as extra tags have been added.  Can 
the questionable ones be identified in such a way that a JOSM todo list can be 
used to correct them rather than throw out all the work that has been done 
adding tags?
I think you are assuming a more top down management arrangement than exists 
with volunteer Canadian mappers.

Thanks John
  


  

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

Re: [Talk-it] pronto soccorso ospedali italiani

[Martin Koppenhoefer]

sent from a phone

> On 3. Feb 2019, at 09:56, Aury88  wrote:
> 
> Se siete d'accordo su questa metodologia, metto il mio account  e poi chi
> vorrà potrà aggiungere il proprio link.


generalmente le pagine che descrivono i features, sono definiti in inglese, e 
le traduzioni dovrebbero essere appunto questo: traduzioni.
Quindi la pagina italiana di amenity=hospital dovrebbe essere una traduzione 
della pagina inglese, e se si intende aggiungere informazioni sarebbe la cosa 
migliore farlo per prima in inglese.

Non è una critica dei contenuti che vuoi mettere, ma è come penso dovrebbe 
funzionare il wiki. 

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

Re: [OSM-talk-fr] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

[Gwenaël Jouvin via Talk-fr]

On peut raisonnablement considérer que l’information donnée par le panneau, ou, 
plus précisément par le panonceau, est parfaitement traduite dans OSM par la 
clef oneway:bicycle=no.
Le panonceau en lui-même n’est pas un aménagement, il ne fait que traduire une 
prescription sur les règles d’accès des véhicules à la voie concernée.

La clef cycleway, elle, ne s’intéresse pas aux règles d’accès mais aux 
aménagements, qu’ils soient légers par du marquage ou lourds par une chaussée 
séparée (track).
S’il n’y a aucun aménagement, ce qui est en soi une information (et 
intéressante pour faire remarquer à une entité publique un manque à la sécurité 
des usagers), la clef cycleway=no me paraît appropriée.


Le 03/02/2019 à 21:32, Romain MEHUT a écrit :
> Un panneau ce n'est pas rien. C'est bien le sens du "et/ou".
> 
> Le dim. 3 févr. 2019 à 21:23, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a écrit :
> 
> Et si on suit cela on ne peut cartographier la différence entre rien et 
> des pictos, donc le tag cycleway ne répond plus à son rôle premier de décrire 
> l'infrastructure, donc la version française est mauvaise.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Florimond Berthoux]

entre rien sur la chaussée et des pictos...
Bref, le opposite ne permet pas décrire précisément l'infrastructure.

Le dim. 3 févr. 2019 à 21:33, Romain MEHUT  a
écrit :

> Un panneau ce n'est pas rien. C'est bien le sens du "et/ou".
>
> Le dim. 3 févr. 2019 à 21:23, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>> Et si on suit cela on ne peut cartographier la différence entre rien et
>> des pictos, donc le tag cycleway ne répond plus à son rôle premier de
>> décrire l'infrastructure, donc la version française est mauvaise.
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-ca] Building Import update

[john whelan]

I accept the nicest way is to check the data beforehand.  Scripting it is
fairly simple.  Are you suggesting a two stage process of take the data and
run the script first then task manager the data to be imported to manually
correct the data?  My eyesight isn't good enough to pick out none right
angled corners so is there some way someone can come up with to feed them
into a JOSM todo list?

However we have a fairly large number of building outlines that have
already been imported.  The issue here is different as extra tags have been
added.  Can the questionable ones be identified in such a way that a JOSM
todo list can be used to correct them rather than throw out all the work
that has been done adding tags?

I think you are assuming a more top down management arrangement than exists
with volunteer Canadian mappers.

Thanks John

On Sun, 3 Feb 2019 at 15:33, Pierre Béland  wrote:

> John
>
> Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier
> la donnée avant l'importation. Des critères comme ceux que j'ai présenté
> pourraient être utilisés dans un script pour simplifier les polygones qui
> sont quasi orthogonaux.
>
> Pour simplifier la procédue d'import, deux fichiers distincts pourraient
> être produits :
>
> 1. Formes géométriques quasi-orthogonales corrigées - import plus rapide -
> mais a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
>
> 2. Formes géométriques irrégulières - Import avec révision / correction
> plus serrée.
>
> Il reste à ceux qui mènent le projet de faire ces développements
> logiciels. Et pourquoi pas, de proposer des outils que les communautés
> locales pourront ensuite utiliser. Par contre éviter qu'un petit groupe
> importe rapidement les données et ignore le rôle des communautés locales.
>
> Et l'argument, si tu t'opposes, tu est responsable pour ta communauté,
> nous ont fait le reste du pays, à mon avis cela ne tient pas la route.
>
> Pierre
>
>
> Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> So you're proposing that a script is run to correct minor deviations in
> the remaining data which sounds a reasonable approach to me and would
> improve data quality.
>
> So run the data through the script.  Then import and run overpass to pick
> out those that need manual adjustment?
>
> If we do this though then I think we need to stay with the single import
> plan rather than have individual import plans popping up that didn't use
> the scripts.
>
> I have no control over the number of mappers importing or the rate at
> which they import and I'm not sure how you would mange this other than
> having a person identified in the wiki as leading a particular area and
> there is provision or rather was I'm not sure what the latest version says.
>
> Even with smaller import plans there would be nothing to stop one mapper
> bringing in building outlines very quickly.
>
> Cheerio John
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Romain MEHUT]

Un panneau ce n'est pas rien. C'est bien le sens du "et/ou".

Le dim. 3 févr. 2019 à 21:23, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Et si on suit cela on ne peut cartographier la différence entre rien et
> des pictos, donc le tag cycleway ne répond plus à son rôle premier de
> décrire l'infrastructure, donc la version française est mauvaise.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

John
Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier la 
donnée avant l'importation. Des critères comme ceux que j'ai présenté 
pourraient être utilisés dans un script pour simplifier les polygones qui sont 
quasi orthogonaux. 

Pour simplifier la procédue d'import, deux fichiers distincts pourraient être 
produits :
1. Formes géométriques quasi-orthogonales corrigées - import plus rapide - mais 
a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
2. Formes géométriques irrégulières - Import avec révision / correction plus 
serrée. 

Il reste à ceux qui mènent le projet de faire ces développements logiciels. Et 
pourquoi pas, de proposer des outils que les communautés locales pourront 
ensuite utiliser. Par contre éviter qu'un petit groupe importe rapidement les 
données et ignore le rôle des communautés locales. 

Et l'argument, si tu t'opposes, tu est responsable pour ta communauté, nous ont 
fait le reste du pays, à mon avis cela ne tient pas la route.
 
Pierre 
 

Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan 
 a écrit :  
 
 So you're proposing that a script is run to correct minor deviations in the 
remaining data which sounds a reasonable approach to me and would improve data 
quality.
So run the data through the script.  Then import and run overpass to pick out 
those that need manual adjustment?
If we do this though then I think we need to stay with the single import plan 
rather than have individual import plans popping up that didn't use the scripts.
I have no control over the number of mappers importing or the rate at which 
they import and I'm not sure how you would mange this other than having a 
person identified in the wiki as leading a particular area and there is 
provision or rather was I'm not sure what the latest version says.
Even with smaller import plans there would be nothing to stop one mapper 
bringing in building outlines very quickly.
Cheerio John


 


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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Florimond Berthoux]

Et si on suit cela on ne peut cartographier la différence entre rien et des
pictos, donc le tag cycleway ne répond plus à son rôle premier de décrire
l'infrastructure, donc la version française est mauvaise.

Le dim. 3 févr. 2019 à 20:36, Romain MEHUT  a
écrit :

> Bonsoir,
>
> La version française du wiki dit pour ce cas de figure "Cyclistes
> autorisés à circuler dans le sens opposé de la circulation générale. Pas de
> voie dédiée, mais de simples marquages ou/et panneaux de signalisations."
>
> Donc même sans voie matérialisée ni marquage au sol, il reste les panneaux
> de signalisation (panneau sens interdit "sauf vélo"dit précédemment) et on
> est toujours à mon sens dans ce schéma S1 comme le dit Truchin.
>
> Romain
>
> Le sam. 2 févr. 2019 à 19:36, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>> C'est ça, et ça rejoint la version anglaise :
>> «Add the cycleway=* tag to a highway=* to map cycling infrastructure that
>> is an inherent part of the road.»
>> puis :
>> «cycleway=opposite
>> Use cycleway=opposite for situations where cyclists are permitted to
>> travel in both directions on a road which is one-way for normal traffic, in
>> situations where there is no dedicated contra-flow lane marked for
>> cyclists. In practice there is typically a very short section of road,
>> sometimes called a "cycle plug", where cycles are excepted from the
>> no-entry by means of a short lane separated by an island. These roads
>> should normally also be tagged with oneway=yes and also oneway:bicycle=no.
>> Streets like this are common in Belgium, the Netherlands and Denmark. They
>> are rarer in the UK, but are becoming more common due to a recent change in
>> road signage allowing no entry signs qualified with "except cycles".»
>>
>> La page française gagnerait en précision.
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

[Talk-at] Einladung zum Stammtisch in Graz am 4.2.2019 (Morgen)

[Michael Maier]

Liebe OpenStreetMap-Interessierte in der Steiermark,

wir laden zu ersten heurigen OSM-Stammtisch in Graz - der 
Jänner-Stammtisch wurde aufgrund Abwesenheit einiger Regulars um eine 
Woche in den Februar hinein auf den 4.2. verschoben.


Der Stammtisch findet um 18:00 im Brot & Spiele in Graz statt -
Tischreservierung auf „OpenStreetMap“, wir sitzen gleich vorne links 
gegenüber der Bar (Nichtraucherbereich).


Zwecks Agenda und sonstigem bitte die Wiki-Seite¹ konsultieren:

[1] https://wiki.openstreetmap.org/wiki/Graz/Stammtisch

Den nächsten Grazer Stammtisch gibts dann voraussichtlich im März.

lg,
Michael

--
Michael Maier, Student of Telematics @ Graz University of Technology
OpenStreetMap Graz http://osm.org/go/0Iz@paV
https://wiki.osm.org/Graz
https://wiki.osm.org/Graz/Stammtisch

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

Re: [Talk-ca] Building Import update

[john whelan]

So you're proposing that a script is run to correct minor deviations in the
remaining data which sounds a reasonable approach to me and would improve
data quality.

So run the data through the script.  Then import and run overpass to pick
out those that need manual adjustment?

If we do this though then I think we need to stay with the single import
plan rather than have individual import plans popping up that didn't use
the scripts.

I have no control over the number of mappers importing or the rate at which
they import and I'm not sure how you would mange this other than having a
person identified in the wiki as leading a particular area and there is
provision or rather was I'm not sure what the latest version says.

Even with smaller import plans there would be nothing to stop one mapper
bringing in building outlines very quickly.

Cheerio John

On Sun, 3 Feb 2019 at 14:09, Pierre Béland  wrote:

> Le «acid test» de John, avec une architecture aussi irrégulière, a abimé
> les «Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur
> Orléans à l'extérieur de la zone étudiée ! Une analyse plus approfondie de
> la zone du centre-ville nous montre qu'il y a peu de telles architectures.
> Cette réponse ne tient pas la route et n'explique pas le ratio élevé de
> polygones avec formes irrégulières dans la base OSM.
>
> Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à
> corriger pour orthognaliser. voir
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html
>
> Ce que je comprends bien aux réactions de John depuis le début, c'est
> laissons les données telles qu'elles.  Plusieurs évitent de se pronconcer.
> Cela ne me convainct pas de l'urgence pour un petit groupe de se hâter à
> importer les données sans tenir compte de problèmes de qualité importants.
>
> J'ai révisé mon script qualité pour cerner davantage les formes
> régulières. Il tenait compte jusqu'ici des angles à 90 degrés et des autres
> formes régulières (hexagones, octogones, etc). Je l'ai révisé au cours des
> derniers jours acceptant une tolérance jusqu'à 5 degrés. Les angles à 45
> degrés  (ie. 45, 135, 225, 315) sont maintenant pris en compte.
>
> Ces modifications ont eu peu d'impact sur le nombre de bâtiments
> identifiés avec formes irrégulières. Cela confirme qu'il a a des polygones
> avec formes qui s'éloignent sensiblement de formes régulières.
>
> Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments
> peuvent être orthogonalisés automatiquement à l’aide de scripts. Ou encore
> il serait possible de réviser tous les bâtiments avec tolérance de 1 à 5
> degrés (ceux à moins de 1 degrés resteraient tels quels. Malgré tout, Il
> reste toujours 25% des bâtiments qui doivent être analysés manuellement et
> voir si des corrections sont nécessaires.
>
>
> Pierre
>
>
> Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I can't think of a way to pull in all the suspect buildings but if you
> have a look here:
>
>
> https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696
>
> 556, 558, 560 are all examples that I think would fail your test.  However
> they are the shape of the buildings.
>
> As far as I am aware we haven't had any outraged users complaining about
> the building shapes in Ottawa and that I think is the acid test.  The
> Ottawa building import has been useful certainly in gaining new mappers and
> adding tags to the outlines.
>
> Your test originally was to pick out very badly mapped buildings that had
> been done in iD and I would agree with you that some were very bad.
> Sometimes 3 or 4 times the size of the building and some very odd shapes
> indeed.  From memory most were done on HOT tasks with the iD editor.
>
> These I think we should definitely aim to avoid but where the
> representation of the building is reasonably accurate then I think they are
> acceptable.  We are using reasonably experienced mappers who would balk at
> importing some of the stuff we saw in Nepal etc and rightly so.  They'd
> almost certainly be very vocal about the quality of the data.
>
> There is a case to be made that most residential buildings would be
> acceptable if they were mapped with the JOSM buildings_tool plugin and all
> the small blobs take up database size.  There is also a case that you get a
> better sense of the building with the small blobs, bay windows etc.  I
> don't have strong feelings either way but I strongly suspect there are
> examples of both already in OSM in Canada.
>
> I note that both Google and Bing have most buildings these days and it has
> almost become a map user expectation.  Certainly there are apps that guide
> blind people that use the building outlines in OSM.  There is a case that
> says to keep up with the competitors we really ought to have buildings.
>
> I think someone else has commented that parts of the Microsoft building
> outline from scanned 

Re: [Talk-ca] Building Import update

[john whelan]

The Ottawa building outline import was done by the local Ottawa mappers to
a standard they were happy with.

Cheerio John

On Sun, 3 Feb 2019 at 14:42, Pierre Béland  wrote:

> De tes exemples sortis du chapeau ne font pas avancer la discussion.
>
> J'attends la démonstration de John que les données d'import pour Ottawa
> représentent bien le contour des bâtiments et sont des données de qualité.
>
> Pierre
>
>
> Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> From OSMweekly 445 and I'm not sure if it is relevant or not.
>
> Cheerio John
>
> Imports
>
>- Frederik Ramm suggested
>
> 
>reverting a four-year-old building import in Ulster County, New York State,
>because only simple squares had been imported instead of the correct
>building outlines. Two years ago the import was featured
>
> 
>by *Worst of OSM*.
>
>
> On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:
>
> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> On squaring buildings, no one has yet been explained why buildings should
> be square.  My understanding is that non-square buildings are a warning
> sign for mapathons with hand-traced buildings - the lack of squaring is
> often noticeable for hand-traced buildings, and indicative of generally
> poor building footprints. That doesn't apply here, since the buildings
> involved are not hand-traced (at least in Toronto).  In fact, the imported
> footprints are generally extremely accurate, much better than would (or
> could) be done by hand.
>
> It seems like the automated verification tool (of checking whether
> buildings are square or not) is being misapplied in this case.
>
> DannyMcD
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> 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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

Pierre writes that he is "waiting for John's demonstration that the import data 
for Ottawa represents the outline of the buildings and is quality data."

In reality, anybody (not necessarily John) can offer this sort of 
characterization.

En réalité, n'importe qui (pas nécessairement John) peut offrir ce type de 
caractérisation.

SteveA

On Feb 3, 2019, at 11:42 AM, Pierre Béland via Talk-ca 
 wrote:
> De tes exemples sortis du chapeau ne font pas avancer la discussion. 
> 
> J'attends la démonstration de John que les données d'import pour Ottawa 
> représentent bien le contour des bâtiments et sont des données de qualité.
>  
> Pierre 


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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

De tes exemples sortis du chapeau ne font pas avancer la discussion. 

J'attends la démonstration de John que les données d'import pour Ottawa 
représentent bien le contour des bâtiments et sont des données de qualité.
 
Pierre 
 

Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan 
 a écrit :  
 
 From OSMweekly 445 and I'm not sure if it is relevant or not.
Cheerio John


Imports
   
   - Frederik Ramm suggested reverting a four-year-old building import in 
Ulster County, New York State, because only simple squares had been imported 
instead of the correct building outlines. Two years ago the import was featured 
by Worst of OSM.

On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

  
If they weren't hand traced, how were they made? I don't believe I've actually 
seen any documentation on this. Do we know how these buildings footprints were 
made? Just because we didn't trace them from imagery ourselves doesn't mean 
someone working for a city GIS department didn't do exactly the same thing some 
time ago. 
 
 
We're concerned with squaring because buildings generally have right angles. If 
the data don't have right angles too, then like you said it likely indicates 
poor quality data. 
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
  On 2/2/19 10:48 AM, Danny McDonald wrote:
  
 On squaring buildings, no one has yet been explained why buildings should be 
square.  My understanding is that non-square buildings are a warning sign for 
mapathons with hand-traced buildings - the lack of squaring is often noticeable 
for hand-traced buildings, and indicative of generally poor building 
footprints. That doesn't apply here, since the buildings involved are not 
hand-traced (at least in Toronto).  In fact, the imported footprints are 
generally extremely accurate, much better than would (or could) be done by 
hand. 
  It seems like the automated verification tool (of checking whether buildings 
are square or not) is being misapplied in this case. 
  DannyMcD  
  ___
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 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] Moulinette pour ajouter "oneway:bicycle=no" ?

[Romain MEHUT]

Bonsoir,

La version française du wiki dit pour ce cas de figure "Cyclistes autorisés
à circuler dans le sens opposé de la circulation générale. Pas de voie
dédiée, mais de simples marquages ou/et panneaux de signalisations."

Donc même sans voie matérialisée ni marquage au sol, il reste les panneaux
de signalisation (panneau sens interdit "sauf vélo"dit précédemment) et on
est toujours à mon sens dans ce schéma S1 comme le dit Truchin.

Romain

Le sam. 2 févr. 2019 à 19:36, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> C'est ça, et ça rejoint la version anglaise :
> «Add the cycleway=* tag to a highway=* to map cycling infrastructure that
> is an inherent part of the road.»
> puis :
> «cycleway=opposite
> Use cycleway=opposite for situations where cyclists are permitted to
> travel in both directions on a road which is one-way for normal traffic, in
> situations where there is no dedicated contra-flow lane marked for
> cyclists. In practice there is typically a very short section of road,
> sometimes called a "cycle plug", where cycles are excepted from the
> no-entry by means of a short lane separated by an island. These roads
> should normally also be tagged with oneway=yes and also oneway:bicycle=no.
> Streets like this are common in Belgium, the Netherlands and Denmark. They
> are rarer in the UK, but are becoming more common due to a recent change in
> road signage allowing no entry signs qualified with "except cycles".»
>
> La page française gagnerait en précision.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Some feedback on import quality in Toronto

[OSM Volunteer stevea]

Mmm, careful with your language, John.  The data "have a license which is 
compatible with OSM's ODbL" (is an accurate way to say it).  I believe that 
took about eight years and was a difficult slog, a lot of hard work by many, 
lessons learned from Ottawa, a determination by OSM's LWG, but it is done.  (I 
am grateful for that, it is an important milestone).

A different issue is whether the data and their concomitant quality "are 
acceptable" to the OSM community.  The license being ODbL compatible is not 
that; these are different issues.  We now discuss data quality (and what to do 
to improve them, if anything) here in talk-ca and in the mildly-being-updated 
Import Plan, with experiences of what Yaro, Danny and Nate have done in Toronto.

It is not the case, as John says, that "the data (are) licensed to be 
acceptable to (OSM)."  The concept of "acceptability" is not related to the 
data being licensed compatible with ODbL.

What often/usually happens is an Import Plan gets wide vetting and acceptance 
by the OSM community before data become imported, including 
suitability/acceptability of the quality of the data.  What happened here is 
the Import Plan was attempted to be widely vetted, but this seems to have been 
largely ignored or little-paid-attention-to.  While the Plan's initial 
shortcomings were pointed out, yet not remedied, the Import began, then the 
community began to react (with some complaint and some "what Yaro does seems 
OK").  Yaro (and Nate, I believe) then updated the Import Plan with Yaro's 
specific technical steps.

Still, complaints and/or disagreements about simplification, squaring and 
potentially other issues continue.  (As two asides, I'll say that MANY 
buildings are not necessarily "square" — like buildings with bay windows — and 
that truly square/rectangular buildings should express this with a tagged 
way/closed polygon made up of exactly four nodes).

As these discussions continue, eventually what will emerge is "how do we 
(algorithmically, manually...) change the data, whether pre-import or 
during-import, so that they achieve wide acceptance as to their quality by the 
community."  We're getting closer, it seems to me, but I don't think we're 
there yet.

Nobody seems to be arguing there is or isn't a "desire to bring in the 
buildings by many" or to "use them for many purposes."  That point seems 
"decided."  The questions remain:  "how, with the existing data?"  Once those 
are determined (and documented in the Import Plan), over time, the data will 
(or will not) be imported.  I wish to offer encouragement to this process, it 
does appear to continue here and can likely bear fruit in the near future.  
Keep going!  Consensus is ahead!

SteveA

On Feb 3, 2019, at 10:55 AM, john whelan  wrote:
> So I suggest that you name yourself as the coordinator on the wiki page for 
> Toronto that allows the local mappers in Toronto to import at the rate and to 
> the standard you suggest.
> 
> For the rest of the country the data is licensed to be acceptable to 
> OpenStreetMap thus anyone can set up their own import plan and import it even 
> if this import is abandoned.  I'd like to see this voiced as the general 
> desire though on talk-ca before it happens as it was a talk-ca decision to 
> proceed.
> 
> My reading of the posts on talk-ca is that there is a desire to bring in the 
> buildings by many.  There is also a desire by many to use them for many 
> purposes.
> 
> Cheerio John
> 
> On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John, 
> You seem to be mostly addressing topics which have been brought up elsewhere. 
> My email was meant to address specific data quality issues in Toronto, so I'm 
> not sure how to respond to all of this. 
> To your broader question though, my position is that we *do* have the 
> volunteers and skills necessary to make this a good import. Supposing that we 
> didn't though, then I would have to say that the import should wait until we 
> have the right people working on it. A bad import is worse than no import.
> 
> Cheers,
> 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-it] Changeset leggermente problematico...

[Sergio Manzi]

Grassie, vecio!  Pecà... el "/Casin dei Nobili/" el xe famoso e fa sempre rider 
tuti... :-)


On 2019-02-03 15:03, Cascafico Giovanni wrote:
> Penso sia soeo question che no ghe stà dentro el rendering: infati se te 
> struchi el botòn "Ricerca degli elementi" li lista coretamente. :-)
>
> Il giorno dom 3 feb 2019 alle ore 13:42 Sergio Manzi  > ha scritto:
>
> Ho sbagliato qualcosa o è pura sfortuna dovuta al fatto che i due 
> toponimi "/non ci stanno/" uno vicino all'altro?
>
>
> ___
> 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: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

 Le «acid test» de John, avec une architecture aussi irrégulière, a abimé les 
«Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur Orléans 
à l'extérieur de la zone étudiée ! Une analyse plus approfondie de la zone du 
centre-ville nous montre qu'il y a peu de telles architectures. Cette réponse 
ne tient pas la route et n'explique pas le ratio élevé de polygones avec formes 
irrégulières dans la base OSM.

Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à 
corriger pour orthognaliser. voir 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html

Ce que je comprends bien aux réactions de John depuis le début, c'est laissons 
les données telles qu'elles.  Plusieurs évitent de se pronconcer. Cela ne me 
convainct pas de l'urgence pour un petit groupe de se hâter à importer les 
données sans tenir compte de problèmes de qualité importants.

J'ai révisé mon script qualité pour cerner davantage les formes régulières. Il 
tenait compte jusqu'ici des angles à 90 degrés et des autres formes régulières 
(hexagones, octogones, etc). Je l'ai révisé au cours des derniers jours 
acceptant une tolérance jusqu'à 5 degrés. Les angles à 45 degrés  (ie. 45, 135, 
225, 315) sont maintenant pris en compte. 

Ces modifications ont eu peu d'impact sur le nombre de bâtiments identifiés 
avec formes irrégulières. Cela confirme qu'il a a des polygones avec formes qui 
s'éloignent sensiblement de formes régulières.

Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments peuvent 
être orthogonalisés automatiquement à l’aide de scripts. Ou encore il serait 
possible de réviser tous les bâtiments avec tolérance de 1 à 5 degrés (ceux à 
moins de 1 degrés resteraient tels quels. Malgré tout, Il reste toujours 25% 
des bâtiments qui doivent être analysés manuellement et voir si des corrections 
sont nécessaires.

 Pierre 
 

Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan 
 a écrit :  
 
 I can't think of a way to pull in all the suspect buildings but if you have a 
look here:
https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696

556, 558, 560 are all examples that I think would fail your test.  However they 
are the shape of the buildings.
As far as I am aware we haven't had any outraged users complaining about the 
building shapes in Ottawa and that I think is the acid test.  The Ottawa 
building import has been useful certainly in gaining new mappers and adding 
tags to the outlines.
Your test originally was to pick out very badly mapped buildings that had been 
done in iD and I would agree with you that some were very bad.  Sometimes 3 or 
4 times the size of the building and some very odd shapes indeed.  From memory 
most were done on HOT tasks with the iD editor.
These I think we should definitely aim to avoid but where the representation of 
the building is reasonably accurate then I think they are acceptable.  We are 
using reasonably experienced mappers who would balk at importing some of the 
stuff we saw in Nepal etc and rightly so.  They'd almost certainly be very 
vocal about the quality of the data.
There is a case to be made that most residential buildings would be acceptable 
if they were mapped with the JOSM buildings_tool plugin and all the small blobs 
take up database size.  There is also a case that you get a better sense of the 
building with the small blobs, bay windows etc.  I don't have strong feelings 
either way but I strongly suspect there are examples of both already in OSM in 
Canada.
I note that both Google and Bing have most buildings these days and it has 
almost become a map user expectation.  Certainly there are apps that guide 
blind people that use the building outlines in OSM.  There is a case that says 
to keep up with the competitors we really ought to have buildings.
I think someone else has commented that parts of the Microsoft building outline 
from scanned images in the US is problematic.
So given the results in Ottawa are comparable to Ontario and in my opinion 
Ottawa is acceptable then I think the rest is also acceptable.  Certainly 
Kingston where not all building angles were right angles weren't noticeable to 
me by eye or perhaps my eyesight is just getting worse with age.
Cheerio John


On Thu, 31 Jan 2019 at 19:51, Pierre Béland  wrote:

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173 

Re: [Talk-ca] Some feedback on import quality in Toronto

[john whelan]

So I suggest that you name yourself as the coordinator on the wiki page for
Toronto that allows the local mappers in Toronto to import at the rate and
to the standard you suggest.

For the rest of the country the data is licensed to be acceptable to
OpenStreetMap thus anyone can set up their own import plan and import it
even if this import is abandoned.  I'd like to see this voiced as the
general desire though on talk-ca before it happens as it was a talk-ca
decision to proceed.

My reading of the posts on talk-ca is that there is a desire to bring in
the buildings by many.  There is also a desire by many to use them for many
purposes.

Cheerio John

On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John,
>
> You seem to be mostly addressing topics which have been brought up
> elsewhere. My email was meant to address specific data quality issues in
> Toronto, so I'm not sure how to respond to all of this.
>
> To your broader question though, my position is that we *do* have the
> volunteers and skills necessary to make this a good import. Supposing that
> we didn't though, then I would have to say that the import should wait
> until we have the right people working on it. A bad import is worse than no
> import.
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/3/19 1:14 PM, john whelan wrote:
>
> My expectation was that the import would be based on the city's records of
> foundations for the buildings.
>
> I would not expect to see sheds etc.and I'd be quite happy to only get
> most of the buildings. The rest can be added by local mappers at a later
> date.
>
> My expectation is they will be consistent and not some mapped from Bing,
> others from ESRI etc.
>
> There are estimated to be in excess of 11,000,000 buildings in Canada.  I
> don't think we have enough skilled mappers to map them all from imagery.
>
> My expectation is the import would give us a reasonable number of fairly
> accurate building outlines at relatively low cost in mapper time.  Missing
> building imports from city open data are now fairly common in many parts of
> the world.
>
> My expectation is that the building outlines would have additional tags
> added and that this would draw in less skilled mappers.  At the same time
> corrections could be made to the outlines if deemed necessary.
>
> It would avoid too many badly mapped buildings.
>
> Before the import started it was raised in talk-ca and there was some
> discussion.  I understand you were not a member at that time or took part
> in that discussion but that doesn't change the fact that the issue was
> discussed.
>
> The idea of a single import plan came from talk-ca and that is why there
> is a single import plan covering the entire country and there was
> discussion on talk-ca on the point.
>
> The original plan on the wiki mentioned having some coordination in an
> area.  I don't think this happened but it was an attempt to give a louder
> local voice as it was recognised it would be better if local mappers took
> the lead.
>
> Different mappers have different ideas of what is acceptable.  I think
> your standards are fairly high thus more demanding in resources and do we
> have enough resources?  I don't think we do to import to the standard at
> which you are asking.
>
> Could you clarify what you are saying?
>
> I assume that for other parts of the country if they wish to continue and
> find the building outlines acceptable they may do so?
>
> Thanks John
>
> Thanks John
>
>
>
> On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:
>
>> Hi all,
>>
>> I had a chance this morning to work on cleaning up some of the
>> already-imported data in Toronto. I wanted to be a little methodical about
>> this, so I picked a single typical block near where I live. All the
>> building data on this block came from the import and I did everything in
>> one changeset: https://www.openstreetmap.org/changeset/66881357
>>
>> What I found was that:
>>
>> 1) Every single building needed squaring
>>
>> 2) Most buildings needed at least some simplification.
>>
>> 3) 42 buildings were missing.
>>
>> I knew going in that the first two would be an issue, but what really
>> surprised me was just how many sheds had not been imported. There are only
>> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
>> quite large, and none of which had been mapped.
>>
>> I haven't seen the quality of the outbuildings in the source data, and
>> maybe I would change my mind if I did, but I think if we're going to do
>> this import properly, we're going to have to bring in the other half of the
>> data. I had seen in the original import instructions that small buildings
>> were being excluded - was there a reason for this?
>>
>> I also want to say: given how long it took me to clean up and properly
>> remap this one block, I'll say again that the size of the import tasks is
>> way, way, way too large. There 

Re: [Talk-it] One feature, one element - scuole

[Lorenzo Mastrogiacomi]

Il giorno dom, 03/02/2019 alle 14.58 +0100, Cascafico Giovanni ha
scritto:
> Recentemente, inserendo parecchie scuole in Friuli Venezia Giulia, mi
> son trovato casi in cui dentro lo stesso poligono amenity=school ci
> stavano più scuole (tipicamente primarie e d'infanzia) con codice
> meccanografico (ref) diverso.
> Come fare per restare nella "buona pratica" del "one feature, one OSM
> element"?
> 
> 
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> 
> ___



La cosa migliore secondo me sarebbe cercare di capire qual'è l'area di
competenza di ciascuna scuola e tracciare quindi le due aree
parzialmente sovrapposte.

Se proprio le due scuole condividono la stessa identica area si possono
usare le relazioni multipoligono per creare più elementi area con lo
stesso unico poligono esterno.
Immagino una poligono senza tag che sarà poi utilizzato in due
relazioni, una per ogni scuola e con i propri tag.


Lorenzo


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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Nate Wessel]

John,

You seem to be mostly addressing topics which have been brought up 
elsewhere. My email was meant to address specific data quality issues in 
Toronto, so I'm not sure how to respond to all of this.


To your broader question though, my position is that we *do* have the 
volunteers and skills necessary to make this a good import. Supposing 
that we didn't though, then I would have to say that the import should 
wait until we have the right people working on it. A bad import is worse 
than no import.


Cheers,

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

On 2/3/19 1:14 PM, john whelan wrote:
My expectation was that the import would be based on the city's 
records of foundations for the buildings.


I would not expect to see sheds etc.and I'd be quite happy to only get 
most of the buildings. The rest can be added by local mappers at a 
later date.


My expectation is they will be consistent and not some mapped from 
Bing, others from ESRI etc.


There are estimated to be in excess of 11,000,000 buildings in 
Canada.  I don't think we have enough skilled mappers to map them all 
from imagery.


My expectation is the import would give us a reasonable number of 
fairly accurate building outlines at relatively low cost in mapper 
time.  Missing building imports from city open data are now fairly 
common in many parts of the world.


My expectation is that the building outlines would have additional 
tags added and that this would draw in less skilled mappers.  At the 
same time corrections could be made to the outlines if deemed necessary.


It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some 
discussion.  I understand you were not a member at that time or took 
part in that discussion but that doesn't change the fact that the 
issue was discussed.


The idea of a single import plan came from talk-ca and that is why 
there is a single import plan covering the entire country and there 
was discussion on talk-ca on the point.


The original plan on the wiki mentioned having some coordination in an 
area.  I don't think this happened but it was an attempt to give a 
louder local voice as it was recognised it would be better if local 
mappers took the lead.


Different mappers have different ideas of what is acceptable.  I think 
your standards are fairly high thus more demanding in resources and do 
we have enough resources?  I don't think we do to import to the 
standard at which you are asking.


Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue 
and find the building outlines acceptable they may do so?


Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel > wrote:


Hi all,

I had a chance this morning to work on cleaning up some of the
already-imported data in Toronto. I wanted to be a little
methodical about this, so I picked a single typical block near
where I live. All the building data on this block came from the
import and I did everything in one changeset:
https://www.openstreetmap.org/changeset/66881357

What I found was that:

1) Every single building needed squaring

2) Most buildings needed at least some simplification.

3) 42 buildings were missing.

I knew going in that the first two would be an issue, but what
really surprised me was just how many sheds had not been imported.
There are only 53 houses on the block, but 42
sheds/garages/outbuildings, some of them quite large, and none of
which had been mapped.

I haven't seen the quality of the outbuildings in the source data,
and maybe I would change my mind if I did, but I think if we're
going to do this import properly, we're going to have to bring in
the other half of the data. I had seen in the original import
instructions that small buildings were being excluded - was there
a reason for this?

I also want to say: given how long it took me to clean up and
properly remap this one block, I'll say again that the size of the
import tasks is way, way, way too large. There is absolutely no
way that someone could have carefully looked at and verified this
data as it was going in. I just spent a half hour fixing up
probably about one-hundredth of a task square.

We can do better than this!

-- 
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: [Talk-ca] Some feedback on import quality in Toronto

[john whelan]

My expectation was that the import would be based on the city's records of
foundations for the buildings.

I would not expect to see sheds etc.and I'd be quite happy to only get most
of the buildings. The rest can be added by local mappers at a later date.

My expectation is they will be consistent and not some mapped from Bing,
others from ESRI etc.

There are estimated to be in excess of 11,000,000 buildings in Canada.  I
don't think we have enough skilled mappers to map them all from imagery.

My expectation is the import would give us a reasonable number of fairly
accurate building outlines at relatively low cost in mapper time.  Missing
building imports from city open data are now fairly common in many parts of
the world.

My expectation is that the building outlines would have additional tags
added and that this would draw in less skilled mappers.  At the same time
corrections could be made to the outlines if deemed necessary.

It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some
discussion.  I understand you were not a member at that time or took part
in that discussion but that doesn't change the fact that the issue was
discussed.

The idea of a single import plan came from talk-ca and that is why there is
a single import plan covering the entire country and there was discussion
on talk-ca on the point.

The original plan on the wiki mentioned having some coordination in an
area.  I don't think this happened but it was an attempt to give a louder
local voice as it was recognised it would be better if local mappers took
the lead.

Different mappers have different ideas of what is acceptable.  I think your
standards are fairly high thus more demanding in resources and do we have
enough resources?  I don't think we do to import to the standard at which
you are asking.

Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue and
find the building outlines acceptable they may do so?

Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> 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

[Talk-ca] Some feedback on import quality in Toronto

[Nate Wessel]

Hi all,

I had a chance this morning to work on cleaning up some of the 
already-imported data in Toronto. I wanted to be a little methodical 
about this, so I picked a single typical block near where I live. All 
the building data on this block came from the import and I did 
everything in one changeset: 
https://www.openstreetmap.org/changeset/66881357


What I found was that:

1) Every single building needed squaring

2) Most buildings needed at least some simplification.

3) 42 buildings were missing.

I knew going in that the first two would be an issue, but what really 
surprised me was just how many sheds had not been imported. There are 
only 53 houses on the block, but 42 sheds/garages/outbuildings, some of 
them quite large, and none of which had been mapped.


I haven't seen the quality of the outbuildings in the source data, and 
maybe I would change my mind if I did, but I think if we're going to do 
this import properly, we're going to have to bring in the other half of 
the data. I had seen in the original import instructions that small 
buildings were being excluded - was there a reason for this?


I also want to say: given how long it took me to clean up and properly 
remap this one block, I'll say again that the size of the import tasks 
is way, way, way too large. There is absolutely no way that someone 
could have carefully looked at and verified this data as it was going 
in. I just spent a half hour fixing up probably about one-hundredth of a 
task square.


We can do better than this!

--
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] Building Import update

[john whelan]

>From OSMweekly 445 and I'm not sure if it is relevant or not.

Cheerio John

Imports

   - Frederik Ramm suggested
   
   reverting a four-year-old building import in Ulster County, New York State,
   because only simple squares had been imported instead of the correct
   building outlines. Two years ago the import was featured
   

   by *Worst of OSM*.


On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> On squaring buildings, no one has yet been explained why buildings should
> be square.  My understanding is that non-square buildings are a warning
> sign for mapathons with hand-traced buildings - the lack of squaring is
> often noticeable for hand-traced buildings, and indicative of generally
> poor building footprints. That doesn't apply here, since the buildings
> involved are not hand-traced (at least in Toronto).  In fact, the imported
> footprints are generally extremely accurate, much better than would (or
> could) be done by hand.
>
> It seems like the automated verification tool (of checking whether
> buildings are square or not) is being misapplied in this case.
>
> DannyMcD
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> 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-us] Wake County Missing Buildings Import

[Leif Rasmussen]

Hi everyone,
Joe Caruso contacted the City of Raleigh about the license of the building
footprints, and received a promising reply.  The data is OSM compatible.
The building import will begin some time soon, after all comments have been
addressed.  The bus stop and address imports will begin after this import
is complete.


* Wiki page:
https://wiki.openstreetmap.org/wiki/Wake_County_North_Carolina_Building_Import
* Tasking Manager Project: https://tasks.openstreetmap.us/project/110
* Size of Import: 31, 730 buildings.


Please let me know if I have missed anything.
Thanks,
Leif Rasmussen
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-fr] remerciements aux traducteurs du hebdoOSM

[David Crochet]

Bonjour

En recevant aujourd'hui le hebdoOSM en français en même temps que 
l'internationale, je voudrait remercier l'équipe de traduction en 
français pour leur travaux et réactivité.


Cordialement

--
David Crochet


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

[Talk-us] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-ko] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

매주 일어나는 OSM 소식을 종합한, 445번째 주간OSM이 발행되었습니다.

http://www.weeklyosm.eu/ko/archives/11447/

읽어 주셔서 감사합니다!

주간OSM이란? 
누가?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
어디서?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

[OSM-talk-fr] hebdoOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 445 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11447/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-pt] semanárioOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 445, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/11447/

Aproveite!

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-ht] hebdoOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 445 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11447/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[Talk-ca] hebdoOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 445 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11447/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-br] semanárioOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 445, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/11447/

Aproveite!

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-africa] hebdoOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 445 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11447/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[OSM-talk] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-GB] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-ca] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-in] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[talk-ph] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-africa] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-it] Changeset leggermente problematico...

[Cascafico Giovanni]

Penso sia soeo question che no ghe stà dentro el rendering: infati se te
struchi el botòn "Ricerca degli elementi" li lista coretamente. :-)

Il giorno dom 3 feb 2019 alle ore 13:42 Sergio Manzi  ha
scritto:

> Ho sbagliato qualcosa o è pura sfortuna dovuta al fatto che i due toponimi
> "*non ci stanno*" uno vicino all'altro?
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] One feature, one element - scuole

[Cascafico Giovanni]

Recentemente, inserendo parecchie scuole in Friuli Venezia Giulia, mi son
trovato casi in cui dentro lo stesso poligono amenity=school ci stavano più
scuole (tipicamente primarie e d'infanzia) con codice meccanografico (ref)
diverso.
Come fare per restare nella "buona pratica" del "one feature, one OSM
element"?

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

[Talk-it] Changeset leggermente problematico...

[Sergio Manzi]

Con il changeset 66874965 (https://www.openstreetmap.org/changeset/66874965) ho 
suddiviso la way 174639282 in due tratte perché era erroneamente indicata come 
"Sotoportego del Casin dei Nobili" (il nome vero è "Calle Lombardo"), mentre 
tale toponimo si applica al /sotoportego/ (tunnel=building_passage) che forma 
la parte più a N della way orignaria e che non era mappato ed ho introdotto 
(way 668044787) splittando la way originale.

Sembra tutto bene, compreso il fatto che entrambe le way sono state mantenute 
nella relation 5561622, "Il Cammino di sant'Antonio - Variante partenza da 
Venezia", ma... visualizzando la mappa nessuno dei due toponimi, né quello 
riferito al sottoportego né quello riferito alla calle, viene visualizzato, 
nemmeno a Z=19.

Ho sbagliato qualcosa o è pura sfortuna dovuta al fatto che i due toponimi 
"/non ci stanno/" uno vicino all'altro?

Grazie in anticipo a chi avrà la pazienza di controllare quanto ho fatto (/e 
correggere, se le riterrà opportuno/),

Sergio



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

Re: [Talk-it-trentino] Una strada verso l'assessorato...?

[Alessandro Vitali]

Ho visto che i link pubblicati non funzionano... per completezza:

- delibera numero 449 del 23 mar 2018
*https://www.dropbox.com/s/yv5yyj943welisp/619676-2018-P001-00039-PR-003.pdf?dl=0
*
- delibera numero 2005 del 19 ott 2018
https://www.dropbox.com/s/s9bte5450sdycly/632292-2018-P001-00137-PR-003.pdf?dl=0

Mercoledì 20 sarò agli workshop di Foss4G a Padova... nel caso ci fosse
qualcuno di voi... per conoscerci

Il giorno dom 20 gen 2019 alle ore 19:21 Renato Conotter <
renato.conot...@gmail.com> ha scritto:

> Ciao seguo la questione abbastanza da dentro: il cartografico presente in
> nue-curl del Trentino viene poi replicato anche alle centrali sanitaria e
> vigili del fuoco.
> Il grado stradale ufficiale è un bagno di sangue! Alcuni comuni
> "illuminati" hanno un buon dato per altri no.
> Il fatto che un ente della provincia faccia queste richieste ai comuni é,
> forse, la migliore soluzione per fare in modo che tutti si attivano.
> Nota dolentissima: il servizio strade che ha un ottimo dato non lo
> fornisce ma si deve estrarlo dal loro sito...
>
>
> Renato Conotter
> www.conotter.net
> invio in mobilità
>
> Il giorno gio 27 dic 2018, 11:48 Maurizio Napolitano 
> ha scritto:
>
>> On Thu, Dec 27, 2018 at 11:08 AM Dario Zontini 
>> wrote:
>> >
>> > No, la richiesta è di avere possibilmente il grafo stradale
>> georeferenziato ma non tutti comuni lo avranno perché non c'è ancora un
>> obbligo di averlo. ISTAT ha appena concluso il censimento permanente della
>> popolazione in cui era previsto di georeferenziare i civici di alcuni
>> indirizzi scelti a campione (saranno circa il 5% del totale) . I rilevatori
>> avevano un normale tablet per Segrate il punto e come potete intuire
>> soprattutto nei centri storici la precisione è stata scarsa. Inoltre questi
>> dati sono di ISTAT e bisogna vedere come verranno rilasciati
>>
>> La tua email conferma le mie perplessità in merito al fatto di fare
>> una richiesta di dati che ancora non esistono e farli convergere anche
>> su OpenStreetMap.
>> il prossimo mese mi dovrebbe essere molto più chiaro il progetto dei
>> numeri civici di cui ho scritto.
>> Sarebbe però molto interessante sapere quanti comuni risponderanno
>> alla richiesta.
>> grazie
>>
>> ___
>> 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

[Talk-at] Fwd: OpenStreetMap Stammtisch Leobersdorf

[Thomas Rupprecht]

Hallo Community,

Ich starte am 28.02.2019, 19 Uhr den *1. OpenStreetMap Stammtisch in
Leobersdorf* im Hacker-/Makerspace */usr/space*.

Es ist jeder herzlichst eingeladen vorbeizukommen. Nur bitte ich um eine
kurze Zu/Absage damit ich die Anzahl der benötigten Plätze schaffen kann.
(Im Wiki eintragen reicht auch)

Meine vorgeschlagenen Themen:

   - Einführung in OpenStreetMap
   - Neue basemap.at Layer
   - Sonnengang API

Weitere gewünschte Themen mir einfach zukommen lassen.

Weitere Infos unter:
https://wiki.openstreetmap.org/wiki/Leobersdorf/Stammtisch

mfg Thomas Rupprecht aka XimeX
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] pronto soccorso ospedali italiani

[EneaSuper]

Ciao Aury, nelle prossime ore dovrei iniziare a lavorare negli ospedali
genovesi. Per quanto riguarda il rendermi disponibile ad aiutare gli altri
mappatori nel fare altrettanto penso che accetterò, ma ti farò sapere nei
prossimi tempi.



--
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-in] OSM India partnership with upcoming YourStory.in conference

[Arun Ganesh]

Hi everyone, happy to share that we are officially community partners with
YourStory for their technology conference Future of Work [1] in Bengaluru
on Feb 9th.

Tickets are priced Rs 4k and YourStory is offering 15 free passes to
members of the OSM India community to attend. This is a great opportunity
to network with folks in the tech sector, so do make use of it.

>From the event site:* Future of Work conference will bring together the
finest minds redefining technology and product innovation, to build
conversation on the new frontiers of technology and talent. Check out some
really exciting speakers in their lineup from from tech, product and design
backgrounds: *
https://events.yourstory.com/future-of-work-2019#Speakers_Present

*They will have a mix of developers, technologists, corporates and CXOs
present in the audience and will like you to be there as well and be a part
of some really interesting conversations.*

*Date – Feb 09, 2019 | Saturday*

*Time - 9 am onwards *
*Venue – MLR Convention Centre, Whitefield, Bengaluru *
https://osm.org/go/yy41UlsqB-?m==1660031400

They have limited seats so request you to register at the earliest. They
will get back to you with the final confirmation and the pass.
Registration link: https://goo.gl/forms/9Wx7Jlw1Ef233CNu2

Please send me a direct mail if you have issues getting the pass. Feel free
to share in other OSM channels.

[1] https://events.yourstory.com/future-of-work-2019

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

Re: [Talk-it] pronto soccorso ospedali italiani

[Aury88]

Come preannunciato, dopo due settimane senza pareri contrari alla
sostituzione della voce, ho provveduto a modificare la pagina wiki IT
dell'amenity=hospital [1] con i contenuti sviluppati sulla mia sandbox
precedentemente linkata.

Vista l'importanza del tema, stavo pensando di integrare la voce con link ad
alcuni  account di volontari disposti a rispondere ad eventuali domande dei
nuovi mappatori per quanto riguarda la mappatura degli ospedali (un esempio
potete trovarlo nella voce wiki del comune di Gela [2]).

Se siete d'accordo su questa metodologia, metto il mio account  e poi chi
vorrà potrà aggiungere il proprio link.

Ne approfitto per avvisare che, per questioni di completezza e come
preannunciato precedentemente, ho tradotto anche la voce dedicata al
emergency=emergency_ward_entrance [3]. 
Per questa voce non c'è stato alcun processo di approvazione trattandosi di
una semplice traduzione dall'inglese e per una voce in italiano non ancora
esistente.

In questa fase è fondamentale rendere lo stile di mappatura più "virale"
possibile in maniera tale da limitare al massimo la confusione sul metodo di
mappatura; chiedo quindi, se potete, di controllare gli ospedali che
conoscete e applicare, la dove necessario, lo stile di mappatura descritto
nella wiki. Grazie

[1]https://wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dhospital
[2]https://wiki.openstreetmap.org/wiki/Gela
[3]https://wiki.openstreetmap.org/wiki/IT:Tag:emergency%3Demergency_ward_entrance



-
Ciao,
Aury
--
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-it] importare dati osm su database

[Andrea Musuruane]

Ciao,

On Thu, Jan 31, 2019 at 7:11 PM Roberto Brazzelli 
wrote:

>
> Ciao Maurizio,
> grazie per le info sotto..sono riuscito a caricare i dati osm.pfb
> con osm2psql ...non ho però per ora installato nulla per quanto
> riguarda il render (mod_tile render/ mapnik ecc)
> Prima di avventurarmi volevo capire cosa fa esattamente:
> - crea tessere vettoriali con i dati osm caricati applicando stile
> predefinito
> tipo “OpenStreetMap Carto”?
> - in che modo posso modificare lo stile di queste tessere per
> personalizzarlo?
> modificando il file di stile di mapnik?
>
>
Prova a leggere questo tutorial (in francese):
https://www.tartarefr.eu/se-construire-un-serveur-de-tuile-openstreetmap/

Ciao,

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