date:20161107

>
> As for Joost's suggestion for mapping shops in a town. Depending on
> the data source, it might add too much out-of-date data. I fear that
> armchair mappers will blindly copy the data without cross referencing
> other sources that indicate that the shop was closed/moved. Using up
> to date photo's from OpenStreetView or Mapillary could overcome this
> problem, when the mapper is willing to spend enough time and does want
> to be the mapper that finishes most tiles in the shortest period.
>

There is no open data source for shops that I'm aware of, so this would in
fact be a collect data + map task. There is of course the option of taking
an area that is already densely mapped in Mapillary (say, central Brussels)
and define a task there. Then the "validation" step would be to go into the
field and collect the last bits of info.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Missing Maps, in Belgium

2016-11-07 Per discussione Marc Gemis

Thanks Jonathan for setting up the server.

I have been thinking about projects, but the ones I can come up with
are better suited for Maproulette:
- direction tag to give_way and stop signs
- adding missing wikipedia/wikidata tags

the second one could be done with a task manager (especially in
combination with the JOSM wikipedia plugin), but as soon as new source
data becomes available, tiles should be marked as not-done. This is
easier/better handled by a Maproulette challenge. But both are really
armchair mapping projects.

As for Joost's suggestion for mapping shops in a town. Depending on
the data source, it might add too much out-of-date data. I fear that
armchair mappers will blindly copy the data without cross referencing
other sources that indicate that the shop was closed/moved. Using up
to date photo's from OpenStreetView or Mapillary could overcome this
problem, when the mapper is willing to spend enough time and does want
to be the mapper that finishes most tiles in the shortest period.

regards

m

On Mon, Nov 7, 2016 at 6:26 PM, joost schouppe  wrote:
> Hi,
>
> It's been on our wishlist for a very long time, and thanks to Jonathan
> Belien, we now have it: a Belgian tasking manager!
>
> Here's an example task [1] ; not Missing Maps Wallonia, but Missing Maps
> Halle. Just showcasing what is easily possible: a specific task for a
> certain area, clear instructions about what we want done, and some sources
> which load straight to JOSM or iD (not Potlatch :)
>
> This is just an example, but there are lots of possibilities!
>
> * Something similar with the Slow Roads inventory
> * mapping buildings in residential areas in Wallonia (you can use polygons
> instead of squares to define a task)
> * map all the shops in a part of town (we could use statistical sectors
> there)
>
> If you have been working on something, and would like some outside help - or
> just keep track of your project - just suggest a task here or on our Trello
> [2].
>
>
> [1]: https://tasks.osm.be/project/2
> [2]: https://trello.com/b/VAMdaGsp/openstreetmap-belgium
>
>
> --
> Joost @
> Openstreetmap | Twitter | LinkedIn | Meetup
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-11-07 Per discussione osm . sanspourriel

En dézoomant l'exemple de ligne droite abusivement arrondie je suis 
tombé sur :


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#15/47.8461/-3.5068

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#16/47.8461/-3.5068

Curieusement c'est au zoom 15 que l'icône indiquant un accès privé est 
plus grand.


Aux niveaux 16 à 20 
 
c'est de l'ordre de la patte de mouche.


S'il faut mettre une patte de mouche c'est plutôt à mon avis aux bas 
niveaux de zoom.


Au niveau 15 on peut aussi voir des accès interdits à des routes trop 
mineures pour être affichées (en osm.org les accès ne sont pas affichés 
au niveau 15 donc le cas des voies de service ne se pose pas).


Je pense qu'il ne faut pas afficher de symboles relatifs à des objets 
que l'on n'affiche pas à ce niveau de zoom.
Je sais, sans doute plus facile à dire qu'à faire sauf à n'afficher les 
restriction qu'au niveau 16.

Jean-Yvon

Le 06/11/2016 à 20:12, David Crochet - david.croc...@free.fr a écrit :

Bonjour


Le 06/11/2016 à 19:51, Stéphane Péneau a écrit :

Ah bon ? Pourtant je ne les vois pas :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.06739/-1.37014 



Il ne sont pas rendu comme le rendu traditionnel. Logique puisque 
natural=tree_row ne doit être que chemin, pas noeud, ni surface.


Cordialement



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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 23:25 GMT+01:00 demon.box :

> 1 - tutto sul segnavia:
>
> tourism=information
> information=guidepost
> emergency=access_point
> ref=3V-55
> ref:emergency=3V-55
>
> 2 - targhetta soltanto per l'emergenza:
>
> emergency=access_point
> ref:emergency=1234
> (in questo modo se esiste potrei anche mettere in ref il codice di
> riferimento della targhetta stessa)
>


per me non c'è motivo di usare ref:emergency invece di "ref". Sarebbe
diverso nel caso ci fosse un ref per emergenze ed un ref diverso per il
palo/cartello, ma in quel caso userei probabilmente comunque ref per il ref
di emergenza e un "ref:post" oppure post_ref per il palo.

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione demon.box

dieterdreist wrote
> In realtà il ref del segnavia della foto è 3v-55 mentre il 3v sarebbe
> quello del sentiero, vero?
> 
> Se fosse così forse metterei come ref il 3v-55 sul nodo e 3v soltanto alla
> route. 

sì certo è così ma qui il ref sella route non è in discussione credo che a
questo punto bisogna accordarsi sul ref:emergency perchè qui da me ho 2
casi:

1 - tutto sul segnavia:

tourism=information
information=guidepost
emergency=access_point
ref=3V-55
ref:emergency=3V-55

2 - targhetta soltanto per l'emergenza:

emergency=access_point
ref:emergency=1234
(in questo modo se esiste potrei anche mettere in ref il codice di
riferimento della targhetta stessa)

che dite?





--
View this message in context: 
http://gis.19327.n8.nabble.com/Progetto-Montagne-Sicure-tp5885272p5885538.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Progetto Montagne Sicure



sent from a phone

> Il giorno 07 nov 2016, alle ore 22:49, demon.box  ha 
> scritto:
> 
> la foto d'esempio è questa (già l'avevo postata):
> 
>  


grazie, mi era sfuggito.
In realtà il ref del segnavia della foto è 3v-55 mentre il 3v sarebbe quello 
del sentiero, vero?

Se fosse così forse metterei come ref il 3v-55 sul nodo e 3v soltanto alla 
route. Il wiki dice per guidepost di mettere il ref (opzionalmente) se vale per 
il guidepost

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

[Talk-it] Nodi con solo name

2016-11-07 Per discussione Federico Cortese

Segnalo che nel comune di Tricarico in Basilicata l'utente angryrag ha
inserito ieri un centinaio di nodi con solo name: alcune saranno
località, ma non conosco la zona e non ho il tempo di approfondire.
Se qualcuno volesse contattare l'utente o commentare i changeset,
questo è un esempio che contiene un po' degli elementi segnalati, ma
la maggior parte dei nodi sono stati inseriti con changeset singoli
(uno per ogni nodo).

https://www.openstreetmap.org/changeset/43447855

Ciao

Federico

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione demon.box

dieterdreist wrote
> Mi sono guardato gli utilizzi di questa chiave e di 188 occorrenze
> (overpass api) si trovano 175 entro un raggio di 3 chilometri intorno a
> Lumezzane (vicino Brescia)
> (...)
> (e tutti sono stati inseriti da un unico utente)

ciao ;-) quell'unico utente sono io.

la foto d'esempio è questa (già l'avevo postata):

 


dieterdreist wrote
> Di questi tutti (?) sembrano duplicare lo stesso valore di “ref” anche in
> “ref:emergency”

dici bene "sembrano" duplicare lo stesso valore di “ref” anche in
“ref:emergency” in realtà in "ref" c'è il codice di riferimento del segnavia
che quasi sempre coincide anche con il codice per il soccorso ma non
sempre...





--
View this message in context: 
http://gis.19327.n8.nabble.com/Progetto-Montagne-Sicure-tp5885272p5885534.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-cz] Foto rozcestníku

2016-11-07 Per discussione Libor Skala

U Chrome je v adresnim řádku žádost o povoleni skriptu, která se objeví po 
prvním spuštění. Firefox ma podobnou ochranu.
-- 
S pozdravem

Libor Skala

Odesláno z telefonu s Androidem pomocí pošty K-9 Mail.

7. listopadu 2016 21:59:45 SEČ, mves72  napsal:
>Zdravím všechny,
>Po včerejší přednášce Miroslava Suchého na konferenci Openalt jsem se
>chtěl
>připojit k editaci turistických tras ve svém okolí. Odpoledne jsem
>vyfotil
>nejbližší rozcestník a pokusil se ho nahrát na openstreetmap.cz
>účet mám, přihlášení proběhlo, ale když dám vyberte fotografii, objeví
>se
>dialog - tam nahraju fotku, ta se v dialogu zobrazí, ale po kliknutí na
>Nahrát fotografii, skončí to dlouhým čekáním a kolečko dole se pořád
>točí a
>točí...
>
>Je nějaké omezení třeba na velikost fotky?
>může to být tím, že nemám zadáno nic v poli licence? - ale tam mi to
>nic
>nenabízí...
>
>Prosím o radu
>
>
>Miloš
>
>
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-es] Buenas práctica al mapear, en la wiki

2016-11-07 Per discussione Diego García

Actualizado con sección uso correcto de la etiqueta name

Un saludo,

El dom., 16 oct. 2016 a las 17:44, Iñaki ()
escribió:

> Buenas tardes:
>
> Buen comentario, sobre todo eso de hacer la "vida más fácil a todos".
> Gracias.
>
> Iñaki
>
> El 16/10/2016 a las 0:16, yo paseopor escribió:
>
> Buenas gente
>
> Os escribo un correo breve para explicaros que a raíz de unos comentarios
> en el grupo de Telegram me he decidido a crear una página en la wiki que
> explique casos concretos y muy sencillos de cómo se deben hacer las cosas
> (y así evitar trabajos superfluos).
> La página es
> https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Buenas_pr%C3%A1cticas y
> os animo a todos y todas a que expongais vuestros casos, a ser posible con
> imagen y todo. Recordad que no es un lugar para pontificar sino para
> hacernos la vida más fácil a todos un poco, ya sabeis, con educación todo
> es debatible, hasta la existencia humana ;)
>
> Vivimos en Matrix? ;)
>
> Salut i bones pràctiques
> yopaseopor
>
>
> ___
> Talk-es mailing 
> listTalk-es@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-es
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-cz] Foto rozcestníku

2016-11-07 Per discussione mves72

Zdravím všechny,
Po včerejší přednášce Miroslava Suchého na konferenci Openalt jsem se chtěl
připojit k editaci turistických tras ve svém okolí. Odpoledne jsem vyfotil
nejbližší rozcestník a pokusil se ho nahrát na openstreetmap.cz
účet mám, přihlášení proběhlo, ale když dám vyberte fotografii, objeví se
dialog - tam nahraju fotku, ta se v dialogu zobrazí, ale po kliknutí na
Nahrát fotografii, skončí to dlouhým čekáním a kolečko dole se pořád točí a
točí...

Je nějaké omezení třeba na velikost fotky?
může to být tím, že nemám zadáno nic v poli licence? - ale tam mi to nic
nenabízí...

Prosím o radu


Miloš
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-ca] New Innovative Map Company

2016-11-07 Per discussione John Marshall

Great work Bradon!

John

On Sun, Nov 6, 2016 at 5:13 PM, Denis Carriere 
wrote:

> This project was truly an awesome journey with Bradon, it was really
> exciting to work together on KrateLabs and the final map products look
> amazing!
>
> Also a big thanks to Shopify & Mapbox <3 for creating awesome tools that
> made this entire project happen.
>
> Can't wait for the next KrateLabs mapping ideas! :)
>
> Cheers,
>
> *~~*
> *Denis Carriere*
> *GIS Software & Systems Specialist*
>
> *Twitter: @DenisCarriere *
> *OSM: DenisCarriere *
> GitHub: DenisCarriere 
> Email: carriere.de...@gmail.com
>
> On Sun, Nov 6, 2016 at 1:17 PM, Heather Leson 
> wrote:
>
>> So great!  Now I need to not live on the road so that I have a wall for
>> it.
>>
>> Congratulations
>>
>> heather
>>
>> Heather Leson
>> heatherle...@gmail.com
>> Twitter/skype: HeatherLeson
>> Blog: textontechs.com
>>
>> On Sun, Nov 6, 2016 at 3:36 PM, Bradon Levalds 
>> wrote:
>>
>>> Hey Stewart,
>>>
>>> Thanks again. I will ensure the correct attributions are visible on both
>>> digitally and printed on the labels we place on the maps themselves.
>>>
>>> Thanks,
>>> Bradon.
>>>
>>> > On Nov 5, 2016, at 1:21 PM, Stewart C. Russell 
>>> wrote:
>>> >
>>> > On 2016-11-05 12:43 PM, Bradon Levalds wrote:
>>> >>
>>> >> This lasering allows only light to pass through the etched artwork
>>> which
>>> >> frosts, creating a unique, contemporary and detailed design of any
>>> >> location in the world with just the click of a button.
>>> >
>>> > These look really nice! I bet it took a load of trial and error to get
>>> > the engraving just so. Having spent a good bit of time laser cutting
>>> and
>>> > etching acrylic, the results look spectacular when you've got the
>>> > settings dialled in.
>>> >
>>> > Hope you've got the attribution* somewhere on the label!
>>> >
>>> > Stewart
>>> >
>>> > *:
>>> > https://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_li
>>> ke_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
>>> >
>>> > ___
>>> > 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Denis Verheyden

Wow, ik heb blijkbaar ongewild een hele discussie afgestoken ;-)

Maar als ik het goed begrepen heb moeten er dus eerst consensus zijn over welke 
tags we gaan gebruiken om de herkomst van de data in OSM terug te kunnen linken 
met het GRB. En doen we de import best op een systematische, gestructureerde 
manier zodat we niet in het wild objecten/gebouwen gewoon gaan deleten en 
daarna los overschrijven met GRB.

In mijn mail klonk ik misschien opdringerig door "binnen een paar maand" als 
actiepunt te stellen, maar dat was niet mijn bedoeling. Ik heb nog andere zaken 
die ik aan OSM kan toevoegen/bewerken die geen GRB-import nodig hebben, dus die 
kan ik misschien eerst aanpakken.

Als ik niet op de bijeenkomst kan geraken zou het wel leuk zijn om de 
uitkomst/notitites hiervan ergens te vinden. Vermits ik eerder een doe-type ben 
op OSM (mappen dus) en geen development-man ben moeten jullie wel me even 
wegwijs hier in maken (lees: de juiste website/blog/wiki-pagina aanwijzen).

Groeten,

Denis

Van: Glenn Plas 
Verzonden: maandag 7 november 2016 13:40
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

Bang !!! kwas u voor ;-)

Great minds ... blah blah.

https://wiki.openstreetmap.org/wiki/GRBimport

Ik denk dat we die snugger moeten aanpakken, eens de import archieven
bekeken, gewoon alles dat ze al gezegd hebben op imports in de kiem smoren.

De gaten is niet echt een probleem , staat wat los van de tool
eigenlijk, je kan dit altijd spatial oplossen.  Maar om een bestaand
gebouw te matchen met een GRB gebouw is echt moeilijk, vaak omdat er een
offset is en als je GRB gebouw over OSM legt kruist dit in veel gevallen
2 gebouwen, nu welke is de juist om met de plugin te mergen?  Dat moet
de mapper beslissen ter plekke.

Glenn

On 07-11-16 13:32, Ben Abelshausen wrote:
>
> 2016-11-07 13:06 GMT+01:00 Glenn Plas  >:
>
> Willen we eens een bijeenkomst organiseren ?  Ik maak daar graag tijd
> voor.  Ik zou heel graag GRB data zien in OSM maar dan wel volgens de
> regels van de data-kunst.  Ik zou eigenhandig op een maand of 2 tijd
> gans Belgie kunnen doen.
>
> Ik moet zeggend dat ik zelf ook al het idee van Jo heb overwogen, om de
> data te 'druppel-laden' ipv te doen alsof dit een massieve import is (en
> dat is het niet).
>
>
> Er is een mail geweest met een datum ergens tijdens een weekend, er komt
> zeker een face-to-face, hopelijk ook over andere dingen dan het GRB ;-)
> Ik vrees wel dat we er niet uit gaan komen die dag als we al niet voor
> die face-to-face het huidige plan eens aftoetsen bij de import lijst.
> Anders gaat het gewoon dezelfde discussie zijn als nu... Ik zou dus
> zeggen, maken die wiki pagina en eens bekijken wat de import lijst ervan
> denkt, dan kunnen we die face-to-face dag de laatste details afspreken
> en wat knopen doorhakken?!
>
> Ik denk trouwens dat het wel mogelijk is om gaten in OSM te detecteren
> of data te vergelijken zonder de source tags over te nemen. Is een pak
> ingewikkelder maar daar wil ik mij wel eens aanzetten. Voordeel is hier
> dat we dan ook de bestaande gebouwen kunnen meenemen in de vergelijking.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

[OSM-talk-be] GRB import case + wiki page need help

Hi everyone,

I like to set things in motion to prepare our semi-automated import.
I've been reviewing many cases where imports have been proposed and it
looks like our semi-automated approach is pretty solid.  Nevertheless,
as it should be, the people from the import workgroup demand we do our
homework.

One of the things I noticed is that there is a lot of focus on the
license of the source data, we'll need to get links in place to the
correct license and all sorts of background information.

I need some help typing this up...   Specifically, can someone who
studied the GRB licensing (I know some are very knowledgeable on that
subject, more than myself) and spread his/her knowledge on the wiki.

I've created a starter page here :
https://wiki.openstreetmap.org/wiki/GRBimport

You can do this ro8ghly, I will fix the markup when needed, I really
need solid content on that.

Meanwhile I'll work on the procedure and example usage cases. I will
also work on getting a technical solid case I can defend personally
(which doesn't mean we cannot deviate from that case) upstream.

we have some really good advantages, as it is NOT a pure mechanical
import and we are expected to validate with surveys (a lot of us already
do, like Marc Gemis does now).  It's a really added value that we have
people doing it the way Marc does and not 'in bulk' like I did with some
test cases (Stekene).

Keep in mind: it was never made to be a bulky full-auto tool and it will
not allow you to use it like that either.  Our manual steps we perform
will be excellent to counter any objections (they rightly have against
full mechanical imports) before they are even made.

So: in short: would love to get help in on this, I really get motivated
to spend more time in building a production ready tool based on my
development work when I see others who got my back on chores I don't
want/can do.

I'll work a more complete short list of tasks/things we need to cover.

Thanks a lot in advance, with all the interest in GRB it should not be
so hard to get 1 to 5 people on board to assist.

I promise: drinks are on me -every- time we meet about this, so please:
don't all just jump on the boat now you know this.

:)

Glenn

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

[OSM-talk-be] Missing Maps, in Belgium

Hi,

It's been on our wishlist for a very long time, and thanks to Jonathan
Belien, we now have it: a Belgian tasking manager!

Here's an example task [1] ; not Missing Maps Wallonia, but Missing Maps
Halle. Just showcasing what is easily possible: a specific task for a
certain area, clear instructions about what we want done, and some sources
which load straight to JOSM or iD (not Potlatch :)

This is just an example, but there are lots of possibilities!

* Something similar with the Slow Roads inventory
* mapping buildings in residential areas in Wallonia (you can use polygons
instead of squares to define a task)
* map all the shops in a part of town (we could use statistical sectors
there)

If you have been working on something, and would like some outside help -
or just keep track of your project - just suggest a task here or on our
Trello [2].


[1]: https://tasks.osm.be/project/2
[2]: https://trello.com/b/VAMdaGsp/openstreetmap-belgium


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-it] Open Data Provincia di Biella

2016-11-07 Per discussione Andrea Musuruane

Ciao,


2016-10-14 13:01 GMT+02:00 Andrea Musuruane :
> Questa settimana ho realizzato uno script di traduzione per lo stradario. Lo
> trovate sempre qui:
> https://github.com/musuruan/osm_imports/tree/master/prov_bi
>
> L'ho fatto perché ho trovato un tool che, partendo da un dataset di terze
> parti, fa il merge con le strade che sono presenti in OpenStreetMap:
> http://www.openstreetmap.org/user/mvexel/diary/36746
>
> Grazie al supporto di Martijn e Gabriela di Telenav sono riuscito a fare una
> prova sulle strade di Mezzana Mortigliengo. Devo dire che il lavoro di
> conflation è davvero buono. Alla fine rimangono da sistemare solo poche cose
> che vengono prontamente segnalate da JOSM Validator.
>
> Credo che questo strumento possa essere molto utile per importare le strade
> mancanti nei comuni meno mappati della Provincia di Biella, in genere quelli
> di montagna, come appunto Mezzana Mortigliengo.

Non mi piace quotarmi da solo, ma volevo riprendere questo thread.

Ho aggiunto la documentazione (in inglese) che riguarda il processo di
import degli open data della Provincia di Biella a partire da questa
pagina:
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella

I vostri commenti sono ovviamente graditi.

Ciao,

Andrea

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

[Talk-br] Programação SotM Latam 2016

2016-11-07 Per discussione Wille


Olá!

Informamos que a programação do *State of the Map Latam 2016* já está 
disponível no site, confira: http://state.osmlatam.org.


Recomendo àqueles que pretendem ir, realizar logo sua inscrição no site.

abraços,
--

Wille Marcel
http://wille.blog.br/
http://maption.com.br/

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 17:04 GMT+01:00 Alfredo Gattai :

> Che ti sembra?




hai una foto di uno di questi segnavia?

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione Alfredo Gattai

>
> la "comunità” ha scritto questa chiave una volta come ipotesi (se capisco
> bene per il numero di una “emergency response section”) in una pagina di
> discussione sul wiki nel 2014 e poi non ha più seguito questo approccio:
> https://wiki.openstreetmap.org/wiki/Talk:WikiProject_
> Emergency_Cleanup#emergency_response_section.3D.2A
>
> Mi sono guardato gli utilizzi di questa chiave e di 188 occorrenze
> (overpass api) si trovano 175 entro un raggio di 3 chilometri intorno a
> Lumezzane (vicino Brescia). Di questi tutti (?) sembrano duplicare lo
> stesso valore di “ref” anche in “ref:emergency”, e tutti sono
> emergency=access_point (e tutti sono stati inseriti da un unico utente)
>
> 11 altri si trovano in un raggio di 3 chilometri intorno ad un paese
> “Olfen” in Germania e di questi nessuno ha il tag emergency=access_point
> (sono amenity=bench oppure tourism=picnic_site)
>
> I rimanenti due oggetti con questa chiave sono 1 parco giochi e un campo
> da calcio, entrambi dentro lo stesso villaggio in Germania, per esempio:
>
> Secondo tag info history l’utilizzo di questa chiave e decrescendo…
>
> Invece se guardi la documentazione nel wiki per emergency=access_point è
> consigliato “ref” e la stragrande maggioranza dei 2391 nodi con questo tag
> ha infatti un “ref” associato.
>


Direi che corrisponde esattamente a quel che serve per il progetto Montagne
Sicure.

Quindi se ho capito bene e' preferibile usare emergency=access_point e
mettere il numero dentro ref, invece highway=emergency_access_point e'
considerato superato.

Se cosi' fosse probabilmente questo sistema anche il mio problema del
signpost, potrei fare

tourism=information
information=signpost
emergency=access_point
ref=
alt_ref=

dove alt_ref contiene il numero che NON ha a che fare con il soccorso.

Che ti sembra?

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione Martin Koppenhöfer

> On 07 Nov 2016, at 15:55, Alfredo Gattai  wrote:
> 
> perche' rispetto a rescue_ref (che non ha precedenti), ref:emergency sembra 
> essere piu' corretta secondo la comunita'.

la "comunità” ha scritto questa chiave una volta come ipotesi (se capisco bene 
per il numero di una “emergency response section”) in una pagina di discussione 
sul wiki nel 2014 e poi non ha più seguito questo approccio: 
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Emergency_Cleanup#emergency_response_section.3D.2A

Mi sono guardato gli utilizzi di questa chiave e di 188 occorrenze (overpass 
api) si trovano 175 entro un raggio di 3 chilometri intorno a Lumezzane (vicino 
Brescia). Di questi tutti (?) sembrano duplicare lo stesso valore di “ref” 
anche in “ref:emergency”, e tutti sono emergency=access_point (e tutti sono 
stati inseriti da un unico utente)

11 altri si trovano in un raggio di 3 chilometri intorno ad un paese “Olfen” in 
Germania e di questi nessuno ha il tag emergency=access_point (sono 
amenity=bench oppure tourism=picnic_site)

I rimanenti due oggetti con questa chiave sono 1 parco giochi e un campo da 
calcio, entrambi dentro lo stesso villaggio in Germania, per esempio: 
https://www.openstreetmap.org/way/39546010

Secondo tag info history l’utilizzo di questa chiave e decrescendo…

Invece se guardi la documentazione nel wiki per emergency=access_point è 
consigliato “ref” e la stragrande maggioranza dei 2391 nodi con questo tag ha 
infatti un “ref” associato.

Ciao,
Martin

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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione Alfredo Gattai

>
>
>
> perché "anche"? È una chiave non documentata e pochissimo usata (183 al
> momento)
>


perche' rispetto a rescue_ref (che non ha precedenti), ref:emergency sembra
essere piu' corretta secondo la comunita'.

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

Re: [Talk-it] Progetto Montagne Sicure



sent from a phone

> Il giorno 07 nov 2016, alle ore 10:16, Alfredo Gattai 
>  ha scritto:
> 
> adottiamo anche noi ref:emergency= per i signpost.


perché "anche"? È una chiave non documentata e pochissimo usata (183 al momento)


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

[OSM-co] [Tappsi] Actualización: Gracias por tus sugerencias

2016-11-07 Per discussione Soporte Tappsi

##- Por favor, escriba su respuesta por encima de esta línea -##

Estás en la lista de personas que reciben copias de esta solicitud de soporte
(1011168). Responde a este correo para agregar un comentario a la solicitud.

Actualizado por: Nicol Hurtado, 7 nov. 12:30 a.m. COT

Hola Andres!

Muchas gracias por compartir esta información tan valiosa para seguir
construyendo y contribuyendo con un servicio de calidad como el que te mereces.
tus sugerencias son muy importantes para nosotros ya que gracias a ellas
podemos identificar nuestras oportunidades de mejora.

Nos encargaremos de escalar tu solicitud para que sea evaluada por el
departamento encargado y tomada en consideración para una mejora en nuestra
plataforma, agradecemos el tiempo que tomaste al compartirnos esta información

Gracias por preferirnos!

**Nicol Hurtado**

_Asesora de Servicio al Cliente_

tappsi.co

Actualizado por: Andres Gomez Casanova, 5 nov. 9:11 p.m. COT

Buenos días,

Primero que todo, deseo felicitarlos por la aplicación que tienen la cual ha
ayudado a mejorar la movilidad en Bogotá.

Como dicha aplicación se apoya en mapas digitales, he observado que usan mapas
de OpenStreetMap. Sin embargo, no veo la respectiva nota que hace referencia a
ellos tal y como se describe en http://www.openstreetmap.org/copyright

Por este motivo, solicito que la próxima versión de la aplicación tenga esta
nota que debe estar sobre los mapas, y la cual hace referencia a nuestra
comunidad de voluntarios que ha dibujado digitalmente el mapa que ustedes
actualmente están usando.

Adjunto imagen de la aplicación Tappsi y el mapa de OpenStreetMap:
http://www.openstreetmap.org/#map=18/4.70909/-74.06124

Cordialmente,

Andres Gomez Casanova
@AngocA
Screen Shot 2016-11-05 at 21.01.10.png
Tapsi.png

Adjunto(s):
Screen Shot 2016-11-05 at 21.01.10.png -
https://tappsi.zendesk.com/attachments/token/Q76XeLMctORgBSZDSiXpZt3Rz/?name=Screen+Shot+2016-11-05+at+21.01.10.png
Tapsi.png -
https://tappsi.zendesk.com/attachments/token/iFniM8p5xusca2TnLRvMFojFQ/?name=Tapsi.png

Este correo electrónico es un servicio de Tappsi.

[J5YK8O-X60L]___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk-fr] [osm-fr] Projet map.osm.fr

2016-11-07 Per discussione Nicolas Dumoulin

Le Mon, 7 Nov 2016 08:52:36 +0100,
Florian LAINEZ  a écrit :

> Salut,
> Super projet qui est très enthousiasmant.
> 
> Je pense que ça serait une bonne idée d'intégrer également les outils
> de visualisation indoor: OpenLevelUp et ID indoor.
> J'en parlais avec PanierAvide qui est chaud pour bosser sur cette
> intégration.
> ça serait la cerise sur le gâteau ;)

Bonne idée !
Je l'ai ajoutée sur la page projet du wiki :
https://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/map.osm.fr

-- 
Nicolas Dumoulin


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

Re: [OSM-talk-fr] Aide

2016-11-07 Per discussione Nicolas Dumoulin

Bonjour,

Ça n'est pas possible actuellement. Ça me paraît compliquer à ajouter
comme fonctionnalité, mais tu peux tenter en suggérant ton idée par
ici :
https://github.com/umap-project/umap/issues/

Le Wed, 3 Aug 2016 10:15:32 +,
nicolas serge sagna  a écrit :
> Je suis débutant dans les webmapping et
> je trouve umap particulière intéressant.
> J'ai déjà réalisé certaines cartes cependant je
> n'arrive pas à personnaliser la recherche ou à créer une boite
> de recherche personnalisée.
> Merci d'avance
> 



-- 
Nicolas Dumoulin


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

Re: [OSM-talk] User group for mapping activities in Wikimedia

2016-11-07 Per discussione Susanna Ånäs

Thank you for asking :)

Mapping is more and more prominently developed in Wikimedia with the Maps
project . The Kartographer extension
 brings the OSM maps
into Wikipedias, and uses the data stored in Wikidata.

Wikimaps has been a series of activities with historical mapping in
Wikimedia and it has produced georeferencing software
 for maps in Wikimedia Commons and other
activities. The goal has been to create an integrated workflow for
historical geodata using Wikimedia and OpenStreetMap technologies and by
these communities.

In this landscape people working with different projects and topics - more
content-oriented or technology-minded - could start coming together and
learning from each other. From this angle it makes sense to invite mappers,
especially those who already work with Wikimedia to join.

I hope this answers your question, and I hope to encourage many cross-overs
in mapping with OSM and Wikimedia projects!

Cheers
Susanna

2016-11-07 14:44 GMT+02:00 Andreas Vilén :

> Not really sure what you mean. Can you start by explaining what Wikimaps
> is and its relation to Openstreetmap?
>
> /Andreas
>
> Skickat från min iPhone
>
> 6 nov. 2016 kl. 12:08 skrev Susanna Ånäs :
>
> Hi all interested in mapping in Wikimedia!
>
>
> I have made a proposal in Wikimedia IdeaLab to create a Wikimaps user
> group.
>
> Do you think that would be a good way for the Wikimedia mapping community
> to go forward?
>
> Wikimaps activities have been focusing on historical mapping, but the user
> group would be made for all mapping related activities. The goal is that
> people with many different ideas for using the geographic component in
> their projects would come together, share their expertise and help each
> other forward.
>
> The user group would give the community an affiliate status within the
> Wikimedia movement, while still keeping the group organic and without
> organizational structures.
>
> If you think you can endorse or join, please visit the page and leave your
> mark!
>
>
> Best,
>
> Susanna Ånäs
>
>
> https://meta.wikimedia.org/wiki/Grants:IdeaLab/Wikimaps_user_group
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] 歩道のバリアフリー対応のマッピング

2016-11-07 Per discussione tomoya muramoto

muramotoです。

あまり詳しくないのですが、車いす向けのルート検索が可能なサービスは
https://wiki.openstreetmap.org/wiki/Routing/online_routers
の"wheelchair"にまとめられているようです。
ただ、
OpenRouteService(http://www.openrouteservice.org/)はドイツのみ、
Routino(http://www.routino.org/uk-leaflet/router.html)はイギリスのみ
の対応のようで、日本で使えるサービスは見つかりませんでした。

また、Wheelchair routing(
https://wiki.openstreetmap.org/wiki/JA:Wheelchair_routing)
というwikiページには、有用なタグ等がまとめられています。

ご参考まで
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Fail : arrondir les angles

2016-11-07 Per discussione Benoit Fournier

Normalement le mainteneur des rendus cycle et transport est au courant. Au
moins un peu par twitter:

https://twitter.com/plepe/status/778321902020460544
> the rounded roads look really strange. I'm not a fan.

réponse du mainteneur :
https://twitter.com/gravitystorm/status/778329686665461760
> yeah, it doesn't look good for sharp corners, but works well everywhere
else. Need to find a good solution.

je viens d'y répondre pour ajouter cet exemple
> a somewhat extreme example found in talk-fr:
>
http://mc.bbbike.org/mc/?lon=-3.503649=47.846508=17=4=mapbox-satellite=mapnik=cyclemap=transport=

Benoît


2016-11-04 12:45 GMT+01:00 Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com>:

> Je ne lis ni la liste, ni le forum international.
> Quelqu'un d'autre y a-t-il rapporté ce problème ?
>
> PY
>
> Le 15 octobre 2016 à 16:27,  a écrit :
>
>> Bonjour, il n'y a pas que les angles droits, les droites aussi peuvent
>> avoir des problèmes : j'avais vu cette route parallèle à la voie ferrée
>>
>> http://www.openstreetmap.org/#map=18/47.84708/-3.50442=C
>> 
>>
>> Les trois voies soient décomposées en deux chemins mais le chemin
>> principal n'étant pas la ligne droite on a un angle arrondi et en
>> conséquence non seulement la route passe sur la maison mais en plus elle
>> passe sur les voies ferrées :
>>
>>
>> Le 15/10/2016 à 10:46, Francescu GAROBY - windu...@gmail.com a écrit :
>>
>> Wow... O_O
>>
>> Ça fait des angles bizarres et surtout, la route se retrouve parfois
>> par-dessus le bâti ! http://www.openstreetmap.org/s
>> earch?query=caen#map=18/49.18006/-0.35829=C
>>
>> Francescu
>>
>> Le 15 octobre 2016 à 10:08, Pierre-Yves Berrard <
>> pierre.yves.berr...@gmail.com> a écrit :
>>
>>> Bonjour,
>>>
>>> Avez-vous remarqué la tentative de rendre les routes moins anguleuses
>>> sur les rendus cyclo et transport ?
>>>
>>> Pas très probant pour les angles droits...
>>> http://www.openstreetmap.org/#map=17/49.11500/6.22699=C
>>>
>>> PY
>>>
>>
>
> ___
> 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] User group for mapping activities in Wikimedia

2016-11-07 Per discussione Andreas Vilén

Not really sure what you mean. Can you start by explaining what Wikimaps is and 
its relation to Openstreetmap?

/Andreas

Skickat från min iPhone

> 6 nov. 2016 kl. 12:08 skrev Susanna Ånäs :
> 
> Hi all interested in mapping in Wikimedia!
> 
> I have made a proposal in Wikimedia IdeaLab to create a Wikimaps user group.
> Do you think that would be a good way for the Wikimedia mapping community to 
> go forward? 
> Wikimaps activities have been focusing on historical mapping, but the user 
> group would be made for all mapping related activities. The goal is that 
> people with many different ideas for using the geographic component in their 
> projects would come together, share their expertise and help each other 
> forward.
> The user group would give the community an affiliate status within the 
> Wikimedia movement, while still keeping the group organic and without 
> organizational structures.
> If you think you can endorse or join, please visit the page and leave your 
> mark!
> 
> Best,
> Susanna Ånäs
> 
> https://meta.wikimedia.org/wiki/Grants:IdeaLab/Wikimaps_user_group
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Ben Abelshausen

2016-11-07 13:06 GMT+01:00 Glenn Plas :

> Willen we eens een bijeenkomst organiseren ?  Ik maak daar graag tijd
> voor.  Ik zou heel graag GRB data zien in OSM maar dan wel volgens de
> regels van de data-kunst.  Ik zou eigenhandig op een maand of 2 tijd
> gans Belgie kunnen doen.
>
> Ik moet zeggend dat ik zelf ook al het idee van Jo heb overwogen, om de
> data te 'druppel-laden' ipv te doen alsof dit een massieve import is (en
> dat is het niet).
>

Er is een mail geweest met een datum ergens tijdens een weekend, er komt
zeker een face-to-face, hopelijk ook over andere dingen dan het GRB ;-) Ik
vrees wel dat we er niet uit gaan komen die dag als we al niet voor die
face-to-face het huidige plan eens aftoetsen bij de import lijst. Anders
gaat het gewoon dezelfde discussie zijn als nu... Ik zou dus zeggen, maken
die wiki pagina en eens bekijken wat de import lijst ervan denkt, dan
kunnen we die face-to-face dag de laatste details afspreken en wat knopen
doorhakken?!

Ik denk trouwens dat het wel mogelijk is om gaten in OSM te detecteren of
data te vergelijken zonder de source tags over te nemen. Is een pak
ingewikkelder maar daar wil ik mij wel eens aanzetten. Voordeel is hier dat
we dan ook de bestaande gebouwen kunnen meenemen in de vergelijking.

Met vriendelijke groeten,
Best regards,

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

Re: [Talk-es] Correos de bienvenida a nuevos usuarios

2016-11-07 Per discussione Francisco Javier

Buenas!

El texto de Miguel, en mi caso, lo veo bien para los usuarios que se
registran en OSM por primera vez o la están liando parla. Para el foro de
senderismo habría que adaptarlo un poco.

De todas formas, si esperáis unos días, estoy arreglando la portada del
wiki en una página de prueba e incluirá un formato estructurado y con
enlaces a los distintos apartados con lo que enlazando el wiki tendrán todo
el contenido a a mano.

PD: En este semana lo paso por la lista  para que le echéis un ojo para ver
si os gusta y estáis descuerdo con la estructura y demás.



El 6 de noviembre de 2016, 21:16, Santi Aguirre 
escribió:

> Hola,
> Recientemente un foro de montaña con mucha actividad http://www.mendiak.
> net ha abierto un subforo dedicado a Openstreetmap [1] y ya son unos
> cuantos los que han empezado a utilizar ID, algunos con bastante
> entusiasmo, para dibujar en el mapa senderos sobre todo. Si no hay
> inconveniente, he pensado abrirles un tema denominado "buena prácticas en
> OSM" y hacer un copia pega del primer texto de Miguel y de buena parte del
> artículo "buenas prácticas" en la wiki [2]
>
> [1] http://www.mendiak.net/foro/viewforum.php?f=522
> [2] https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%A1cticas
>
> El mié., 26 oct. 2016 a las 15:40, Miguel Sevilla-Callejo (<
> msevill...@gmail.com>) escribió:
>
>> Hola,
>>
>> Al hilo de la conversación que hemos iniciado en Telegram/Riot/loquesea
>> sobre los errores que ha venido teniendo algunos usuarios nuevos en
>> diferentes lugares y como me quedé encargado de hacer algo así como un
>> protocolo de bienvenida, se me ha ocurrido sugeriros algún que otro texto
>> que redacté para aconsejar/dar la bienvenida a OSM vía los mensajes de la
>> web.
>>
>> Así mismo, os invito a que compartáis igualmente, alguno de estos correos
>> y, de ese modo nos sirvan de guías para generar un texto común y un
>> protocol ode bienvenida que iría a la wiki.
>>
>> Ahí van mis mensajes que podrían servir de ejemplo/base (he suprimido los
>> nombres de usuario):
>>
>> # A ---> Este lo escribí hoy para alertar a un nuevo usuario de
>> seguir un protocolo
>>
>> Estimado ,
>>
>> Desde hace unos días hemos detectado desde la comunidad de colaboradores
>> que estas editando para OpenStreetMap lo que nos alegra y aprovechó para
>> darte la bienvenida.
>>
>> Cuando uno se adentra por primera vez en la edición de este proyecto es
>> importante seguir una serie de protocolos de buenas prácticas para
>> contribuir lo mejor posible a la mejora de los datos de este mapa
>> colaborativo.
>>
>> Para empezar te recomiendo no solo que sigas el tutorial de iD (que veo
>> que es el editor que estas usando), que se encuentra embebido a través de
>> un botón de la propia página (abajo a la derecha), si no que le eches un
>> vistazo a la página de referencia y documentación del proyecto, la wiki, en
>> su apartado de iniciación a la edición: http://wiki.openstreetmap.org/
>> wiki/ES:Gu%C3%ADa_del_principiante
>>
>> Otra página web de referencia para empezara editar es:
>> http://learnosm.org/es/
>>
>> Por favor, échale un vistazo a esa documentación.
>>
>> Entre las normas de protocolo y edición que te mencionaba está el no
>> tocar nada de lo previamente editado si no se está seguro de lo que se
>> hace. Es conveniente ponerse en contacto con los otros editores de tu zona
>> y si reeditas alguna de los elementos que están ya allí es interesante que
>> se lo comentes.
>>
>> Puedes ponerte en contacto con la comunidad en España a través de: - la
>> lista de correos: https://lists.openstreetmap.org/listinfo/talk-es - a
>> través de mensajería instántánea por varias vías (todas conectadas a la
>> misma conversación): - usando Telegram: https://telegram.me/OSMes - a
>> tráves de Riot.im (no es necesario darse de alta):
>> https://riot.im/app/#/room/#openstreetmap-es:matrix.org
>>
>> Allí te aconsejaremos y ayudaremos a resolver tus dudas.
>>
>> Por ejemplo, cada vez que haces un conjunto de cambios (le das a salvar
>> en iD) has de incluir un comentario que sea ilustrativo de tus cambios y un
>> "Es así" no cumple ese cometido. Por favor revisa tu forma de introducir
>> datos.
>>
>> Por otro lado, iD muestra por defecto la imagen de satélite de Bing pero
>> esa imagen no tien por que está correctamente localizada en el espacio y ya
>> hemos detectado en varias ocasiones que da problemas, por ello, si vas a
>> editar con esta herramienta te recomendamos que la configures para que use
>> las ortofotografías del IGN (que llevan las siglas PNOA), tienes más
>> información de cómo hacerlo y por qué usarla en estos enlaces: - "rollo
>> teórico" de por qué usar PNOA frente a Bing: https://lists.openstreetmap.
>> org/pipermail/talk-es/2015-November/013555.html - cómo usar PNOA en iD:
>> http://imgur.com/a/GgdVW
>>
>> Espero que esto te sea de utilidad.
>>
>> Lo dicho, bienvenido a la comunidad y esperamos pdamos hacer crecer
>> entretodos este magnífico mapa

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

On 07-11-16 12:44, Ben Abelshausen wrote:
> Het is duidelijk dat dit, vanuit technologie standpunt de beste
> oplossing is, dat is niet waar het probleem zit. Dit is zeker een
> elegante oplossing. Het punt is dat we die wiki pagina moeten maken en
> er moet community consensus zijn (min-of-meer) over de aanpak en ik
> geloof niet dat we dat op deze manier gaan bereiken.

Verschil is natuurlijk dat ik hier al een jaar mee bezig ben en het
normaal is dat mijn keuze's worden ontleed.  Altijd bereid om mijn
standpunten te verduidelijken , ook naar de werkgroep toe.

> 
> Het is 100% zeker dat dit zever gaat geven met de import lijst en data
> working group en ik heb gewoon geen goesting om mij daar weer mee bezig
> te houden. En ik bedoel inderdaad mensen die op eigen houtje GRB
> gebouwen over de bestaande hebben gezet... dat moeten we vermijden.

Dat is echt nasty, maar importeren zonder tags is voor mij net hetzelfde
zootje.

> 
> Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen
> éénmalig te importeren en dan verder te onderhouden op de gangbare
> manier. Dit gaat de weg van de minste pijn zijn, eenvoudig te
> implementeren en geen (of minder) zever met de data working group of de
> import lijst.

Dan kan je dat dus niet automatiseren en of Q/A tools gaan maken, iets
dat ik ook van plan ben achteraf. zoals mijn Urbis Q/A tool :
https://github.com/gplv2/urbis-validate

> 
> In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die
> tags allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te
> verdedigingen op de import lijst.

Ik wil dit wel op mij nemen.

> 
> Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel
> deze discussie via mail te voeren...

Och, het is al paar keer langsgekomen, ik verwacht ook dat we erover
discussieren, maar de impact van de keuzes moet wel duidelijk zijn, als
dat niet zo is kom je hier niet goed uit.

> 
> @marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook
> logischer omdat enkel de data die in die changeset nieuw is ook die bron
> heeft.

Daar ben ik 150% mee akkoord, ik zou VEEL liever source=GRB op de
changeset zetten (geloof dat ik dat meestal ook wel deed)

Willen we eens een bijeenkomst organiseren ?  Ik maak daar graag tijd
voor.  Ik zou heel graag GRB data zien in OSM maar dan wel volgens de
regels van de data-kunst.  Ik zou eigenhandig op een maand of 2 tijd
gans Belgie kunnen doen.

Ik moet zeggend dat ik zelf ook al het idee van Jo heb overwogen, om de
data te 'druppel-laden' ipv te doen alsof dit een massieve import is (en
dat is het niet).

GLenn

> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

On 07-11-16 12:44, Jo wrote:
> source:geometry zou toch hetzelfde moeten zijn als source, wat het
> volgen van de wiki betreft.

Ja, hoe gek is dat niet hee:  Natuurlijk hebben jullie dat process niet
meegemaakt maar toen ik dit initieel had gemaakt stond het er ook zo bij:

source=GRB
source:geometry=GRB
source:position=GRB

En die 2 laatste blijken tegenwoordig hetzelfde te zijn (zie wiki). Dus
die hebben we toen gedropped, en dan wat liggen praten over
source/source:geometry

"Pretty clear it comes from GRB" ;-)

> 
> Persoonlijk vind ik ref beter. Toen ik alle ref op de bushaltes had
> overgezet naar ref:De_Lijn en ref:TEC, kreeg ik van Franse kant wel de
> opmerking dat dit eigenlijk ref:BE:De_Lijn en ref:BE:TEC had moeten zijn.

Je moet echt eens lezen over ref en source verschillen.  Ik heb hier wss
weken aan gespendeerd dus ik ben heel zeker dat ref een minder goede
keuze zal blijken.  Ik geef toe dat je hard moet nadenken over de
intepretaties ervan.  Voor mij is het grote verschil:  een ref dat
slaagt direct op het object.  Terwijl een source tag een referentie is
naar de brondata van een object.

> 
> Maar het maakt me dus niet uit of het source:huppeldepup of ref:...
> wordt. Ik ben ook voorstander van het te verdelen over meerdere tags.

Weet je dat er gebouwen zijn aan de grenzen die zowel in BAG zitten als
in GRB? Dus whatever you do: het mag die BAG data niet ontkrachten of
clashing tags bevatten.  Vandaar dat ik ook een probleem heb met
source=GRB tags

Glenn

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Jo

Ik zou dat vooral zo blijven doen. Kleinschalig, maar beetje bij beetje
geraken de gebouwen er dan toch accuraat in.

Jo

Op 7 november 2016 12:52 schreef Marc Gemis :

> wat ik vooral jammer vind is dat het allemaal redelijk lang aansleept.
> (ik wijs naar niemand)
> Het is gewoon niet leuk om nu nog manueel gebouwen te gaan tekenen als
> je weet dat die toch gaan vervangen worden door betere examplaren.
> En je hebt die gebouwen nu eenmaal nodig om erfgoed tags of andere
> zaken te mappen. Je kan dan niet gewoon maar een puntje zetten.
>
> Dus ja, ik gebruik Glenn's tool nu al om die gebouwen te tekenen die
> ik nodig heb. Gemakkelijker en beter dan wat ik zelf zou tekenen.
> We mogen GRB toch als achtergrond gebruiken, niet ?
>
> m
>
>
> 2016-11-07 12:44 GMT+01:00 Ben Abelshausen :
> > Het is duidelijk dat dit, vanuit technologie standpunt de beste oplossing
> > is, dat is niet waar het probleem zit. Dit is zeker een elegante
> oplossing.
> > Het punt is dat we die wiki pagina moeten maken en er moet community
> > consensus zijn (min-of-meer) over de aanpak en ik geloof niet dat we dat
> op
> > deze manier gaan bereiken.
> >
> > Het is 100% zeker dat dit zever gaat geven met de import lijst en data
> > working group en ik heb gewoon geen goesting om mij daar weer mee bezig
> te
> > houden. En ik bedoel inderdaad mensen die op eigen houtje GRB gebouwen
> over
> > de bestaande hebben gezet... dat moeten we vermijden.
> >
> > Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen
> éénmalig
> > te importeren en dan verder te onderhouden op de gangbare manier. Dit
> gaat
> > de weg van de minste pijn zijn, eenvoudig te implementeren en geen (of
> > minder) zever met de data working group of de import lijst.
> >
> > In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die
> tags
> > allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te
> > verdedigingen op de import lijst.
> >
> > Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel
> > deze discussie via mail te voeren...
> >
> > @marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook
> > logischer omdat enkel de data die in die changeset nieuw is ook die bron
> > heeft.
> >
> > Met vriendelijke groeten,
> > Best regards,
> >
> > Ben Abelshausen
> >
> > Met vriendelijke groeten,
> > Best regards,
> >
> > Ben Abelshausen
> >
> > 2016-11-07 12:14 GMT+01:00 Marc Gemis :
> >>
> >> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
> >> combineren met data die je op een andere manier hebt gevonden (bv. via
> >> survey of wikipedia).
> >> source:geometry of iets dergelijks ok, maar niet source aub.
> >>
> >> m.
> >>
> >> 2016-11-07 12:02 GMT+01:00 Glenn Plas :
> >> > On 07-11-16 11:51, Ben Abelshausen wrote:
> >> >> Glenn,
> >> >>
> >> >> Kijkend naar de BAG import wat denk je van dit:
> >> >>
> >> >> source = GRB
> >> >> ref:grb = 3746049-6379775 (oidn-uidn)
> >> >
> >> > Dat gaat een leuke query worden in de database, met regular
> expressions
> >> > en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> >> > dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> >> > nummer zegt echt niks.
> >> >
> >> > Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> >> > een source ref.  daarom source:*
> >> >
> >> >> Die datum is niet echt relevant voor mappers en als ik het goed
> begrijp
> >> >> kunnen we dit via bovenstaande ref nog altijd uit de originele data
> >> >> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
> >> >> gebruiken om andere tags te genereren omdat daar toch wel
> verschillende
> >> >> zaken inzitten precies.
> >> >
> >> > Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
> >> >>
> >> >> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> >> >> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van
> mappers
> >> >> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar
> >> >> mijn
> >> >> menig een slechte zaak is.
> >> >
> >> > Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history
> van
> >> > een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries
> te
> >> > migreren.  zie docs : http://grbtiles.byteless.net/docs/
> >> >
> >> >>
> >> >> Eens de import klaar is en we hebben alle gebouwen doen we
> maintenance
> >> >> zoals we dat normaal zouden organiseren moest het GRB niet bestaan.
> We
> >> >> kunnen nog altijd de datasets vergelijken om te bekijken waar de
> >> >> wijzigingen zitten.
> >> >
> >> > Die maintenance is nu simpel:  match entity en oidn en je weet exact
> >> > welk gebouw je hebt.
> >> >
> >> > Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> >> > versta niet wat het grote probleem is en waarom we het ons moeilijker
> >> > moeten maken ook als het makkelijk kan ?
> >> >
>

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Marc Gemis

wat ik vooral jammer vind is dat het allemaal redelijk lang aansleept.
(ik wijs naar niemand)
Het is gewoon niet leuk om nu nog manueel gebouwen te gaan tekenen als
je weet dat die toch gaan vervangen worden door betere examplaren.
En je hebt die gebouwen nu eenmaal nodig om erfgoed tags of andere
zaken te mappen. Je kan dan niet gewoon maar een puntje zetten.

Dus ja, ik gebruik Glenn's tool nu al om die gebouwen te tekenen die
ik nodig heb. Gemakkelijker en beter dan wat ik zelf zou tekenen.
We mogen GRB toch als achtergrond gebruiken, niet ?

m


2016-11-07 12:44 GMT+01:00 Ben Abelshausen :
> Het is duidelijk dat dit, vanuit technologie standpunt de beste oplossing
> is, dat is niet waar het probleem zit. Dit is zeker een elegante oplossing.
> Het punt is dat we die wiki pagina moeten maken en er moet community
> consensus zijn (min-of-meer) over de aanpak en ik geloof niet dat we dat op
> deze manier gaan bereiken.
>
> Het is 100% zeker dat dit zever gaat geven met de import lijst en data
> working group en ik heb gewoon geen goesting om mij daar weer mee bezig te
> houden. En ik bedoel inderdaad mensen die op eigen houtje GRB gebouwen over
> de bestaande hebben gezet... dat moeten we vermijden.
>
> Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen éénmalig
> te importeren en dan verder te onderhouden op de gangbare manier. Dit gaat
> de weg van de minste pijn zijn, eenvoudig te implementeren en geen (of
> minder) zever met de data working group of de import lijst.
>
> In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die tags
> allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te
> verdedigingen op de import lijst.
>
> Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel
> deze discussie via mail te voeren...
>
> @marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook
> logischer omdat enkel de data die in die changeset nieuw is ook die bron
> heeft.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> 2016-11-07 12:14 GMT+01:00 Marc Gemis :
>>
>> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
>> combineren met data die je op een andere manier hebt gevonden (bv. via
>> survey of wikipedia).
>> source:geometry of iets dergelijks ok, maar niet source aub.
>>
>> m.
>>
>> 2016-11-07 12:02 GMT+01:00 Glenn Plas :
>> > On 07-11-16 11:51, Ben Abelshausen wrote:
>> >> Glenn,
>> >>
>> >> Kijkend naar de BAG import wat denk je van dit:
>> >>
>> >> source = GRB
>> >> ref:grb = 3746049-6379775 (oidn-uidn)
>> >
>> > Dat gaat een leuke query worden in de database, met regular expressions
>> > en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
>> > dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
>> > nummer zegt echt niks.
>> >
>> > Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
>> > een source ref.  daarom source:*
>> >
>> >> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
>> >> kunnen we dit via bovenstaande ref nog altijd uit de originele data
>> >> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
>> >> gebruiken om andere tags te genereren omdat daar toch wel verschillende
>> >> zaken inzitten precies.
>> >
>> > Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
>> >>
>> >> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
>> >> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
>> >> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar
>> >> mijn
>> >> menig een slechte zaak is.
>> >
>> > Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
>> > een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
>> > migreren.  zie docs : http://grbtiles.byteless.net/docs/
>> >
>> >>
>> >> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
>> >> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
>> >> kunnen nog altijd de datasets vergelijken om te bekijken waar de
>> >> wijzigingen zitten.
>> >
>> > Die maintenance is nu simpel:  match entity en oidn en je weet exact
>> > welk gebouw je hebt.
>> >
>> > Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
>> > versta niet wat het grote probleem is en waarom we het ons moeilijker
>> > moeten maken ook als het makkelijk kan ?
>> >
>> > Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
>> >
>> > Glenn
>> >
>> >
>> >>
>> >> Met vriendelijke groeten,
>> >> Best regards,
>> >>
>> >> Ben Abelshausen
>> >>
>> >> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas > >> > wrote:
>> >>
>> >> On 07-11-16 11:22, Glenn Plas wrote:
>> >> > (hence source:geometry:entity=GRB.
>> >>
>> >> Dju, dat

Re: [Talk-TW] Working together in improving Taiwan roads

2016-11-07 Per discussione maning sambale

Hi,

Final update on this realignment effort.

We completed the realignment project by validating 42 TM projects
covering (~70%) of mainland Taiwan.
See srividya's diary here:
http://www.openstreetmap.org/user/srividya_c/diary/39839

Along with this, we also updated the offset database for areas we
encountered that Bing imagery has an offset, see:
http://www.openstreetmap.org/user/BharataHS/diary/39752

One more cleanup task is needed which is the overlap of buildings and
roads this is available as a tofix task for the community:
http://osmlab.github.io/to-fix/#/task/crossinghighwaysandbuildings

We will work on this in the coming weeks but the majority of
realigning effort is done.

In behalf of the Mapbox data team, we would like to thank the TW
community for supporting this project.
We are looking forward for more collaboration in the future.  Thank again!



Maning Sambale
Data, Mapbox

On Fri, Oct 14, 2016 at 6:16 PM, maning sambale
 wrote:
> Hi,
>
> Quick note to keep the community updated on this.
>
> Today we are wrapping-up re-alignment of Taiwan roads using
> Bing/Mapbox and Strava.
> We created 42 TM projects covering 25K km^2 (~70%) of mainland Taiwan.
> Approximately 57K kms of roads (48% OSM roads) were improved. We will
> continue validating and we appreciate if the community will help as
> well.
>
> As always please don't hesitate to comment on our mapping ticket:
> https://github.com/mapbox/mapping/issues/233
>
> BTW, it was great to personally meet several OSMers of Taiwan at
> SOTM-Asia 2016 in Manila.  Looking forward for more collaboration with
> your awesome community in the future.
>
>
> Maning Sambale
> Data, Mapbox



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Jo

source:geometry zou toch hetzelfde moeten zijn als source, wat het volgen
van de wiki betreft.

Persoonlijk vind ik ref beter. Toen ik alle ref op de bushaltes had
overgezet naar ref:De_Lijn en ref:TEC, kreeg ik van Franse kant wel de
opmerking dat dit eigenlijk ref:BE:De_Lijn en ref:BE:TEC had moeten zijn.

Maar het maakt me dus niet uit of het source:huppeldepup of ref:... wordt.
Ik ben ook voorstander van het te verdelen over meerdere tags.

Jo

Op 7 november 2016 12:39 schreef Glenn Plas :

> On 07-11-16 12:14, Marc Gemis wrote:
> > Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
> > combineren met data die je op een andere manier hebt gevonden (bv. via
> > survey of wikipedia).
> > source:geometry of iets dergelijks ok, maar niet source aub.
>
> En spijtig genoeg is dit verplicht als je de wiki erop naleest
>
> Ik had liever dit gehad :
>
> source:geometry=GRB
>
> Makes more sense, zegt letterlijk:  de geometry komt uit GRB.  Nu heb je
> idd nog adress data, en die kan van CRAB komen.
>
> Maar je kan dit niet importeren zonder source tags volgens de regels...
>
> Ik was dus eerder fan van deze tag, indertijd wel wat over gediscussierd
> met Sander en hebben voor deze gekozen.
>
> Laat het wel verstaan: voor mijn tool is die source tag niet van belang.
>  Dit is om compliant te zijn aan OSM regels.
>
> Dus ik ben akkoord dat dit eigenlijk niet echt nuttig is, maar het is
> wel verplicht, ik sta open voor alternatieven.
>
> Glenn
>
>
> >
> > m.
> >
> > 2016-11-07 12:02 GMT+01:00 Glenn Plas :
> >> On 07-11-16 11:51, Ben Abelshausen wrote:
> >>> Glenn,
> >>>
> >>> Kijkend naar de BAG import wat denk je van dit:
> >>>
> >>> source = GRB
> >>> ref:grb = 3746049-6379775 (oidn-uidn)
> >>
> >> Dat gaat een leuke query worden in de database, met regular expressions
> >> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> >> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> >> nummer zegt echt niks.
> >>
> >> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> >> een source ref.  daarom source:*
> >>
> >>> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
> >>> kunnen we dit via bovenstaande ref nog altijd uit de originele data
> >>> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
> >>> gebruiken om andere tags te genereren omdat daar toch wel verschillende
> >>> zaken inzitten precies.
> >>
> >> Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
> >>>
> >>> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> >>> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
> >>> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar
> mijn
> >>> menig een slechte zaak is.
> >>
> >> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> >> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> >> migreren.  zie docs : http://grbtiles.byteless.net/docs/
> >>
> >>>
> >>> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
> >>> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
> >>> kunnen nog altijd de datasets vergelijken om te bekijken waar de
> >>> wijzigingen zitten.
> >>
> >> Die maintenance is nu simpel:  match entity en oidn en je weet exact
> >> welk gebouw je hebt.
> >>
> >> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> >> versta niet wat het grote probleem is en waarom we het ons moeilijker
> >> moeten maken ook als het makkelijk kan ?
> >>
> >> Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
> >>
> >> Glenn
> >>
> >>
> >>>
> >>> Met vriendelijke groeten,
> >>> Best regards,
> >>>
> >>> Ben Abelshausen
> >>>
> >>> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas  >>> > wrote:
> >>>
> >>> On 07-11-16 11:22, Glenn Plas wrote:
> >>> > (hence source:geometry:entity=GRB.
> >>>
> >>> Dju, dat moest zijn:
> >>>
> >>> source:geometry:entitity=Gbg of Knw, maar niet GRB.
> >>>
> >>> Glenn
> >>>
> >>>
> >>> ___
> >>> Talk-be mailing list
> >>> Talk-be@openstreetmap.org 
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Talk-be mailing list
> >>> Talk-be@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>>
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Ben Abelshausen

Het is duidelijk dat dit, vanuit technologie standpunt de beste oplossing
is, dat is niet waar het probleem zit. Dit is zeker een elegante oplossing.
Het punt is dat we die wiki pagina moeten maken en er moet community
consensus zijn (min-of-meer) over de aanpak en ik geloof niet dat we dat op
deze manier gaan bereiken.

Het is 100% zeker dat dit zever gaat geven met de import lijst en data
working group en ik heb gewoon geen goesting om mij daar weer mee bezig te
houden. En ik bedoel inderdaad mensen die op eigen houtje GRB gebouwen over
de bestaande hebben gezet... dat moeten we vermijden.

Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen éénmalig
te importeren en dan verder te onderhouden op de gangbare manier. Dit gaat
de weg van de minste pijn zijn, eenvoudig te implementeren en geen (of
minder) zever met de data working group of de import lijst.

In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die
tags allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te
verdedigingen op de import lijst.

Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel
deze discussie via mail te voeren...

@marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook
logischer omdat enkel de data die in die changeset nieuw is ook die bron
heeft.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

2016-11-07 12:14 GMT+01:00 Marc Gemis :

> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
> combineren met data die je op een andere manier hebt gevonden (bv. via
> survey of wikipedia).
> source:geometry of iets dergelijks ok, maar niet source aub.
>
> m.
>
> 2016-11-07 12:02 GMT+01:00 Glenn Plas :
> > On 07-11-16 11:51, Ben Abelshausen wrote:
> >> Glenn,
> >>
> >> Kijkend naar de BAG import wat denk je van dit:
> >>
> >> source = GRB
> >> ref:grb = 3746049-6379775 (oidn-uidn)
> >
> > Dat gaat een leuke query worden in de database, met regular expressions
> > en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> > dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> > nummer zegt echt niks.
> >
> > Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> > een source ref.  daarom source:*
> >
> >> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
> >> kunnen we dit via bovenstaande ref nog altijd uit de originele data
> >> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
> >> gebruiken om andere tags te genereren omdat daar toch wel verschillende
> >> zaken inzitten precies.
> >
> > Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
> >>
> >> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> >> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
> >> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
> >> menig een slechte zaak is.
> >
> > Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> > een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> > migreren.  zie docs : http://grbtiles.byteless.net/docs/
> >
> >>
> >> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
> >> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
> >> kunnen nog altijd de datasets vergelijken om te bekijken waar de
> >> wijzigingen zitten.
> >
> > Die maintenance is nu simpel:  match entity en oidn en je weet exact
> > welk gebouw je hebt.
> >
> > Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> > versta niet wat het grote probleem is en waarom we het ons moeilijker
> > moeten maken ook als het makkelijk kan ?
> >
> > Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
> >
> > Glenn
> >
> >
> >>
> >> Met vriendelijke groeten,
> >> Best regards,
> >>
> >> Ben Abelshausen
> >>
> >> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas  >> > wrote:
> >>
> >> On 07-11-16 11:22, Glenn Plas wrote:
> >> > (hence source:geometry:entity=GRB.
> >>
> >> Dju, dat moest zijn:
> >>
> >> source:geometry:entitity=Gbg of Knw, maar niet GRB.
> >>
> >> Glenn
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org 
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >> 
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

On 07-11-16 12:14, Marc Gemis wrote:
> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
> combineren met data die je op een andere manier hebt gevonden (bv. via
> survey of wikipedia).
> source:geometry of iets dergelijks ok, maar niet source aub.

En spijtig genoeg is dit verplicht als je de wiki erop naleest

Ik had liever dit gehad :

source:geometry=GRB

Makes more sense, zegt letterlijk:  de geometry komt uit GRB.  Nu heb je
idd nog adress data, en die kan van CRAB komen.

Maar je kan dit niet importeren zonder source tags volgens de regels...

Ik was dus eerder fan van deze tag, indertijd wel wat over gediscussierd
met Sander en hebben voor deze gekozen.

Laat het wel verstaan: voor mijn tool is die source tag niet van belang.
 Dit is om compliant te zijn aan OSM regels.

Dus ik ben akkoord dat dit eigenlijk niet echt nuttig is, maar het is
wel verplicht, ik sta open voor alternatieven.

Glenn


> 
> m.
> 
> 2016-11-07 12:02 GMT+01:00 Glenn Plas :
>> On 07-11-16 11:51, Ben Abelshausen wrote:
>>> Glenn,
>>>
>>> Kijkend naar de BAG import wat denk je van dit:
>>>
>>> source = GRB
>>> ref:grb = 3746049-6379775 (oidn-uidn)
>>
>> Dat gaat een leuke query worden in de database, met regular expressions
>> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
>> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
>> nummer zegt echt niks.
>>
>> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
>> een source ref.  daarom source:*
>>
>>> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
>>> kunnen we dit via bovenstaande ref nog altijd uit de originele data
>>> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
>>> gebruiken om andere tags te genereren omdat daar toch wel verschillende
>>> zaken inzitten precies.
>>
>> Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
>>>
>>> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
>>> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
>>> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
>>> menig een slechte zaak is.
>>
>> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
>> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
>> migreren.  zie docs : http://grbtiles.byteless.net/docs/
>>
>>>
>>> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
>>> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
>>> kunnen nog altijd de datasets vergelijken om te bekijken waar de
>>> wijzigingen zitten.
>>
>> Die maintenance is nu simpel:  match entity en oidn en je weet exact
>> welk gebouw je hebt.
>>
>> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
>> versta niet wat het grote probleem is en waarom we het ons moeilijker
>> moeten maken ook als het makkelijk kan ?
>>
>> Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
>>
>> Glenn
>>
>>
>>>
>>> Met vriendelijke groeten,
>>> Best regards,
>>>
>>> Ben Abelshausen
>>>
>>> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas >> > wrote:
>>>
>>> On 07-11-16 11:22, Glenn Plas wrote:
>>> > (hence source:geometry:entity=GRB.
>>>
>>> Dju, dat moest zijn:
>>>
>>> source:geometry:entitity=Gbg of Knw, maar niet GRB.
>>>
>>> Glenn
>>>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

On 07-11-16 12:12, joost schouppe wrote:
> 
> >
> > source = GRB
> > ref:grb = 3746049-6379775 (oidn-uidn)
> 
> Dat gaat een leuke query worden in de database, met regular expressions
> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> nummer zegt echt niks.
> 
> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> een source ref.  daarom source:*
> 
> 
> Dus beter datum geometrie + oidn, niet uidn. (+ type eenheid)

die uidn zat er eerst zelfs niet in, de datum vond ik veel interessanter
om te vermijden dat mensen toch geomtrie gaan aanpassen op basis van
oudere sat foto's.  En dat is ondertussen al gebeurd btw met het beetje
dat is geimporteerd ondertussen.

Ik vind het beter hoe het nu staat (evidently)  en ik bekijk dit vanuit
een programmer/sysadmin standpunt ook.  Ik weet uit ervaring dat dit
beetje extra taggin werkt gewoon ons later zoveel hoofdpijn gaat besparen.

> 
> Die tag uiteen trekken als data is iets dat enkel voor onderhoud nodig
> gaat zijn - dus iets complex wordt nog net iets complexer. Lijkt mij
> niet zo'n groot probleem.

> 
>  
> 
> > Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> > (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
> > overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
> > menig een slechte zaak is.
> 
> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> migreren.  zie docs : http://grbtiles.byteless.net/docs/
> 
> 
> 
> Dat is niet wat Ben bedoelt. Hij heeft het op de wilde imports, of
> mensen die overtekenen uit het GRB zonder respect voor wat er al stond.
> Dat lijkt mij trouwens het beste argument voor een grote import: als we
> het niet doen met jouw excellente tool, dan gaan mensen het toch doen,
> alleen veel slechter.

Ha, idd, ik heb die ook al gezien, dan heb je dus enkel geomtries
aangepast, in lokeren geloof ik dat er zo'n geval is, iemand heeft daar
los GRB data geimporteerd, zonder onderverdeling in gebouwen/tags etc.
zonder die source tags kan je hier niets mee, zelfs ik nu niet, tenzij
ik spatial queries ga bouwen en dan nog is het lastig als iemand
ondertussen een gebouw heeft aangepast.

>  
> 
> > Eens de import klaar is en we hebben alle gebouwen doen we maintenance
> > zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
> > kunnen nog altijd de datasets vergelijken om te bekijken waar de
> > wijzigingen zitten.
> 
> Die maintenance is nu simpel:  match entity en oidn en je weet exact
> welk gebouw je hebt.
> 
> 
> Ik heb ook altijd begrepen dat de uitdaging bij importeren up to date
> houden is. Als daar technologische middelen voor zijn, dan moeten we die
> toch gebruiken. Ik snap net als jij niet wat de meerwaarde is van de GRB
> gebouwen ENKEL als OSM objecten te gaan updaten. Ideaal toch als we
> zowel the crowd als het AIV (AGIV) kunnen gebruiken?

Vandaar die source tags!  en natuurlijk is het super dan de crab tool
complementair bleek te zijn na analyse/code.

> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> versta niet wat het grote probleem is en waarom we het ons moeilijker
> moeten maken ook als het makkelijk kan ?
> 
> 
> It's politics baby, niet te veel energie aan verspillen.

Dus, we vragen gewoon meer, we includen alle source tags en als er een
issue is dan moeten ze de data zelf bekijken en zullen ze vaststellen
dat dit de MVP is ( minimum viable product )

Als hostage kunnen we uidn dan afgeven als we de datum bewaren.

Maar eerlijk gezegd,  ik snap de vragen omtrent die tags volledig, maar
zeggen zonder de data te bekijken dat het niet echt nodig is is iets te
snel door de bocht, ik verwacht van de OSM upstream organisatie
onderbouwde argumenten die ik dan snel technisch kan weerleggen, maar
emotie en/of politics heeft hier maar weinig ruimte en begrip bij mij
als de technologische oplossing minderwaardig blijkt te zijn.

Ik wou dat Sander ook even zijn 2c. hier kwam bijsteken :)

Glenn

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

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Marc Gemis

Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
combineren met data die je op een andere manier hebt gevonden (bv. via
survey of wikipedia).
source:geometry of iets dergelijks ok, maar niet source aub.

m.

2016-11-07 12:02 GMT+01:00 Glenn Plas :
> On 07-11-16 11:51, Ben Abelshausen wrote:
>> Glenn,
>>
>> Kijkend naar de BAG import wat denk je van dit:
>>
>> source = GRB
>> ref:grb = 3746049-6379775 (oidn-uidn)
>
> Dat gaat een leuke query worden in de database, met regular expressions
> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> nummer zegt echt niks.
>
> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> een source ref.  daarom source:*
>
>> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
>> kunnen we dit via bovenstaande ref nog altijd uit de originele data
>> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
>> gebruiken om andere tags te genereren omdat daar toch wel verschillende
>> zaken inzitten precies.
>
> Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
>>
>> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
>> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
>> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
>> menig een slechte zaak is.
>
> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> migreren.  zie docs : http://grbtiles.byteless.net/docs/
>
>>
>> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
>> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
>> kunnen nog altijd de datasets vergelijken om te bekijken waar de
>> wijzigingen zitten.
>
> Die maintenance is nu simpel:  match entity en oidn en je weet exact
> welk gebouw je hebt.
>
> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> versta niet wat het grote probleem is en waarom we het ons moeilijker
> moeten maken ook als het makkelijk kan ?
>
> Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
>
> Glenn
>
>
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas > > wrote:
>>
>> On 07-11-16 11:22, Glenn Plas wrote:
>> > (hence source:geometry:entity=GRB.
>>
>> Dju, dat moest zijn:
>>
>> source:geometry:entitity=Gbg of Knw, maar niet GRB.
>>
>> Glenn
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-be
>> 
>>
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

>
>
> >
> > source = GRB
> > ref:grb = 3746049-6379775 (oidn-uidn)
>
> Dat gaat een leuke query worden in de database, met regular expressions
> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> nummer zegt echt niks.
>
> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> een source ref.  daarom source:*
>

Dus beter datum geometrie + oidn, niet uidn. (+ type eenheid)

Die tag uiteen trekken als data is iets dat enkel voor onderhoud nodig gaat
zijn - dus iets complex wordt nog net iets complexer. Lijkt mij niet zo'n
groot probleem.



> > Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> > (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
> > overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
> > menig een slechte zaak is.
>
> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> migreren.  zie docs : http://grbtiles.byteless.net/docs/


Dat is niet wat Ben bedoelt. Hij heeft het op de wilde imports, of mensen
die overtekenen uit het GRB zonder respect voor wat er al stond.
Dat lijkt mij trouwens het beste argument voor een grote import: als we het
niet doen met jouw excellente tool, dan gaan mensen het toch doen, alleen
veel slechter.


> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
> > zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
> > kunnen nog altijd de datasets vergelijken om te bekijken waar de
> > wijzigingen zitten.
>
> Die maintenance is nu simpel:  match entity en oidn en je weet exact
> welk gebouw je hebt.
>
>
Ik heb ook altijd begrepen dat de uitdaging bij importeren up to date
houden is. Als daar technologische middelen voor zijn, dan moeten we die
toch gebruiken. Ik snap net als jij niet wat de meerwaarde is van de GRB
gebouwen ENKEL als OSM objecten te gaan updaten. Ideaal toch als we zowel
the crowd als het AIV (AGIV) kunnen gebruiken?



> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> versta niet wat het grote probleem is en waarom we het ons moeilijker
> moeten maken ook als het makkelijk kan ?
>

It's politics baby, niet te veel energie aan verspillen.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

>
> waarom ?  met welk doel ?  Waarom is een extra tag een probleem?  Nu
> maak je het gewoon moeilijker om queries te draaien zoals: geef me alles
> van entity:GRB
>

Mij kan het niet schelen, is puur pragmatisch om gezever op de import lijst
te voorkomen.
De queries worden niet onmogelijk.


Klopt maar er staat veel crap in CRAB.  Op de bruul in mechelen staan
> een nummer of 10 midden in de straat, wss wisten ze niet waar ze deze
> moesten parkeren.  Dat heb je niet in GRB.
>

Klopt, dat soort dingen kom je nog tegen. Die kan je ook eenvoudig uit CRAB
wegfilteren door adressen die niet aan een gebouw gekoppeld zijn weg te
filteren.



>  crab adress data is niet gekoppeld
> aan een fysiek gebouw, die van GRB wel want er is maar 1 adress dat je
> kan zetten op een gebouw.  Met crab kan je wel indelen in appartementnrs
> etc.  Daar is de CRAB meerwaarde.
>

CRAB is gekoppeld aan gebouwen als relationele database. Dat wordt
vereenvoudigd in GRB door een spatial join te doen.


>
> In de import zijn alle gebouwen met dubbele adressen gedropped (de tags
> toch, niet het gebouw).  vaak huizen op de hoek van 2 straten met 2
> adressen maar met maar 1 gebouw, en in OSM kunnen we dat niet 2
> addressen op 1 building.  Dan werken we met entrance nodes.
>

Yep, dat is de juiste keuze. Ik zou dat veralgemenen naar alle gebouwen met
meerdere hoofd-adressen, maar dat is nog een extra discussie.


> Daarom is de finishing touch eens GRB is geimporteerd om de CRAB tool te
> gebruiken om te vervolledigen op de hoeken.


Yep, strak plan.


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?


>> Kijkend naar de BAG import wat denk je van dit:
>>
>> source = GRB
>> ref:grb = 3746049-6379775 (oidn-uidn)


Entity ontbreekt, gaat niet werken, die oidn's die 'uniek' zijn, zijn
het enkel per entity. Dus entity is echt onontbeerlijk.

Het maakt een overpass query ook moeilijker, nu verleg je het
'performance/excess data probleem' dat je aankaart naar extra load voor
overpass API, als we dan toch issues hebben over wat extra tags/text,
dat vind ik erger.

Ik heb dit ook niet alleen bedacht, ik heb veel input van Sander gehad.

Glenn


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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

On 07-11-16 11:45, joost schouppe wrote:
> Om het aantal tags verder naar beneden te krijgen, zou
> je source:geometry:entity en source:geometry:oidn gewoon samen kunnen
> voegen, niet? Bijvoorbeeld: Gbg_3746049.

waarom ?  met welk doel ?  Waarom is een extra tag een probleem?  Nu
maak je het gewoon moeilijker om queries te draaien zoals: geef me alles
van entity:GRB

> Analyse kwaliteit GRB is spot on.
> 
> Wat betreft verschil in kwaliteit tussen GRB en CRAB:
> 
> - de adressen in CRAB zijn beter, aangezien daar het volledige datamodel
> in zit (een notatie gekoppeld aan een locatie en aan gebouwen). Het GRB
> krijgt slechts, met vertraging, de adresnotatie mee van de adressen waar
> de adrespositie toevallig in ligt. Enkel CRAB kan dus overweg met één
> adres dat bij meerdere gebouwen hoort, of één gebouw waar adressen in
> verschillende straten bij horen.

Klopt maar er staat veel crap in CRAB.  Op de bruul in mechelen staan
een nummer of 10 midden in de straat, wss wisten ze niet waar ze deze
moesten parkeren.  Dat heb je niet in GRB.  Wat er in GRB zit is gewoon
beter.  Kwa compleetheid is CRAB wss wel vollediger.

> 
> - de gebouwen in GRB en CRAB zijn in principe identiek. Wanneer er een
> adres onstaat voor een nieuw gebouw, dan wordt er doorgaans een ruw
> blokje ingetekend als huis. Dat geeft soms het idee van lage kwaliteit.
> Maar als het GRB daar nog iets heeft, dan is dat per definitie
> verouderd. Uiteindelijk wordt het gebouw ingemeten, en komt dan eerst in
> GRB en dan in CRAB terecht. Daar kan mogelijk enige vertraging opzitten,
> dus dan is GRB tijdelijk inderdaad beter.

Het grote verschil is dit eigenlijk: crab adress data is niet gekoppeld
aan een fysiek gebouw, die van GRB wel want er is maar 1 adress dat je
kan zetten op een gebouw.  Met crab kan je wel indelen in appartementnrs
etc.  Daar is de CRAB meerwaarde.

In de import zijn alle gebouwen met dubbele adressen gedropped (de tags
toch, niet het gebouw).  vaak huizen op de hoek van 2 straten met 2
adressen maar met maar 1 gebouw, en in OSM kunnen we dat niet 2
addressen op 1 building.  Dan werken we met entrance nodes.

Daarom is de finishing touch eens GRB is geimporteerd om de CRAB tool te
gebruiken om te vervolledigen op de hoeken.

> 
> (misschien kan iemand van het AIV-AGIV hier nog enkele punten op de i
> zetten)

Yup, dat zou wel interessant zijn.

> 
> Welke verschillen zie jij nog, Glenn?

Het concept vooral, ik vind GRB meer bottom up approach en crab is meer
top-down -do I make sense?

Daarmee dat het GRB per gebouw 1 adress is voor OSM, we kunnen dat niet
mappen met 2 adressen, de GRB database laat dit wel toe.  Wij moeten een
vertaalslag maken naar het OSM model.  We kunnen simpelweg niet 2
addr:street tags maken voor 1 gebouw...   We kunnen dit wel met
addressed entrance nodes.

Glenn

> 
> 2016-11-07 11:29 GMT+01:00 Glenn Plas  >:
> 
> On 07-11-16 11:22, Glenn Plas wrote:
> > (hence source:geometry:entity=GRB.
> 
> Dju, dat moest zijn:
> 
> source:geometry:entitity=Gbg of Knw, maar niet GRB.
> 
> Glenn
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

2016-11-07 Per discussione Ben Abelshausen

Glenn,

Kijkend naar de BAG import wat denk je van dit:

source = GRB
ref:grb = 3746049-6379775 (oidn-uidn)

Die datum is niet echt relevant voor mappers en als ik het goed begrijp
kunnen we dit via bovenstaande ref nog altijd uit de originele data halen?
Zelfde voor entity? We zouden die entity types ook nog kunnen gebruiken om
andere tags te genereren omdat daar toch wel verschillende zaken inzitten
precies.

Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
(bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
menig een slechte zaak is.

Eens de import klaar is en we hebben alle gebouwen doen we maintenance
zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
kunnen nog altijd de datasets vergelijken om te bekijken waar de
wijzigingen zitten.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas  wrote:

> On 07-11-16 11:22, Glenn Plas wrote:
> > (hence source:geometry:entity=GRB.
>
> Dju, dat moest zijn:
>
> source:geometry:entitity=Gbg of Knw, maar niet GRB.
>
> Glenn
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Lot Talk-fr, Vol 124, Parution 15

2016-11-07 Per discussione Cédric PERRIER


Bonjour et merci à Pierre Yves,
la solution à mon problème est trouvée (afficher une image par point).
Je déclarais l'image entre "{{" et "}}" (elles font parti de mes données 
et son hébergées sur framapic) ce qui semble logique selon l'aide 
provenant du point d'interrogation de Umap.
En fait, il faut utiliser les triples crochets comme pour une iframe. 
Là, ça marche.

Allez savoir pourquoi...

En tous cas, grand merci à Pierre Yves Berrard.

Le 05/11/2016 13:00, talk-fr-requ...@openstreetmap.org a écrit :

Envoyez vos messages pour la liste Talk-fr à
talk-fr@openstreetmap.org

Pour vous (dés)abonner par le web, consultez
https://lists.openstreetmap.org/listinfo/talk-fr

ou, par email, envoyez un message avec 'help' dans le corps ou dans le
sujet à
talk-fr-requ...@openstreetmap.org

Vous pouvez contacter l'administrateur de la liste à l'adresse
talk-fr-ow...@openstreetmap.org

Si vous répondez, n'oubliez pas de changer l'objet du message afin
qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..."


Thèmes du jour :

1. insertion d'image dans Umap ou Framacarte (Cédric PERRIER)
2. Re: insertion d'image dans Umap ou Framacarte
   (Pierre-Yves Berrard)
3. Atelier « Initiation à la cartographie avec OpenStreetMap
   » samedi 12/11 (Donat ROBAUX)
4. questions osmose (Julien Lepiller)
5. Re: questions osmose (mga_geo)


--

Message: 1
Date: Fri, 4 Nov 2016 13:09:30 +0100
From: Cédric PERRIER 
To: "talk-fr@openstreetmap.org" 
Subject: [OSM-talk-fr] insertion d'image dans Umap ou Framacarte
Message-ID: <581c7a7a.5030...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Bonjour,
J'espère ne pas abuser en m'adressant à vous mais il me semble que les
utilisateurs d'OSM sont aussi utilisateurs (souvent) de Umap et
Framacarte, si je m'égare, n'hésitez pas à m'en informer. Je n'en
prendrai pas ombrage.
J'utilise Umap et Framacarte.
je souhaite afficher des images (elles sont stockées en ligne sur
framapic) dans une popup.
Chaque image est différente par PIG.
Tant j'arrive à la faire afficher par son adresse complète (ce qui n'est
pas le but puisque chaque PIG a sa propre image) ou afficher l'URL, tant
je n'arrive pas à afficher l'image propre à chaque point.
Dans les options d'interaction du calque en question, j'ai activé "nom
et description (large)" et entré les valeurs suivantes dessous :
{name}
{{image}} 

A l'affichage, j'ai un cadre vide pointant sur une adresse telle que :
"https://umap.openstreetmap.fr/fr/map/image;.
L'adresse de l'image en question est la suivante :
https://framapic.org/GGNsnAS98eTP/f8b7OjsOmv5m.jpg

Auriez vous une piste à me proposer ou une solution si vous avez
rencontré la même difficulté?

Merci



--
Cédric PERRIER
Conseil départemental
Médiateur Numérique
Référent Open Street Map
cartographie libre (http://openstreetmap.fr)
Portable : 06 32 73 79 40
Mail : cedric.perr...@nievre.fr
Nota : afin de contribuer au respect de l’environnement, merci de n’imprimer ce 
courriel qu’en cas de nécessité


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [Talk-es] Correos de bienvenida a nuevos usuarios

Hola,

Estan bienvenidos de utilizar el simple "welcoming tool" que usamos en
Belgica.

Nuestro mensaje de bienvenida esta disponible aca:
https://hackpad.com/OSM-be-welcome-message-BrjHFZdOqS0

Pueden probarlo aqui, con su cuenta OSM:
https://welcome.osm.be

El codigo esta aca:
https://github.com/osmbe/osm-welcome-belgium

Lo que hace es tomar el RSS de nuevos contribuidores por pais de Pascal
Neis y detectar idioma. Al usar el boton "Welcome now" te da el mensaje en
el idioma sugerida. Haciendo ctrl+c copia y abre nuevo mensaje al
contribuidor. Ahi haces ctrl+v y listo!

Como tal lo hace facil de hacer este trabajo en grupo, ya que puedes
filtrar los usuarios que ya recibieron mensaje. Agregando notas sobre lo
que hicieron, hace facil contralar despues de un rato los usuarios que
hicieron algo raro.

Para España, el RSS seria:
http://resultmaps.neis-one.org/newestosmcountryfeed.php?c=Spain

Tambien se puede hacer por bounding box, pero hace trabajar juntos mas
complicado.
http://resultmaps.neis-one.org/newestosmcreatefeed.php



Otra cosa: la explicacion sobre el capa de fondo es bastante technica para
un novato. No conozco la situacion en España, para aqui en Belgica (o por
lo menos Bruselas y Flandes) el capa de fondo estandar en iD son los fotos
de AGIV, que es de calidad mucho mas alto que Bing. No se podria hacer esto
alla?


Un saludo,
Joost



2016-11-06 23:48 GMT+01:00 yo paseopor :

> no objeto nada en que copieis todos los mails que he enviado a usuarios
> noveles más o menos trolls, algunas partes creo que son útiles. Sobretodo,
> de entrada debe quedar claro el espíritu de integración, más que de
> exclusión aunque la caguen mucho. Es gente nueva y con mucha energía, bien
> dirigida serán grandes editores, serán nuestros futuros compañeros de
> charlas, tutoriales, encuentros y otras mandangas para las que necesitamos
> mucha gente.
>
> pequeño punto de vista aportado
> Salut i usuaris novells
> yopaseopor
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-cz] OpenAlt - otevřená data

2016-11-07 Per discussione Ladislav Nesnera

Díky za shrnutí. Mě, žel, povinnosti odvály do jiných koutů areálu a
tento souhrn mi přišel vhod (y)


On 06/11/16 14:14, Jethro wrote:
> Zdar,
> včera jsem se na OpenAltu účastnil přednášky a následné diskuse na
> téma otevřená data ve státní správě, tak posílám shrnutí:
> Komunita ohledně opendat v ČR je hlavně na Twitteru:
> https://twitter.com/hashtag/opendatacz
> Úředníci na všechno potřebují normy a nařízení a jsou z principu předposraní.
> Koordinátoři chtějí aplikace používající otevřená data, aby mohli
> argumentovat, proč data otevírat.
> Pokud máte nějaké aplikace používající opendata, dejte o nich vědět na
> Twitter nebo Michalu Kubáňovi (michal.ku...@mvcr.cz).
> Byla vznesena otázka, jaká CC licence je kompatibilní s Odbl,
> převládal názor, že žádná, nekompatibilita je problém, bylo by dobré,
> kdyby to s nimi někdo z OSM, kdo ovládá právo, vyřešil.
> Za OSM jsem vyjádřil zájem o jakákoli opendata, která jsou udržována
> aktuální, zmiňována byla parkoviště a jiné městské prvky.
>
> Z konkrétních věcí jsme probírali:
> Veřejná doprava: Problém jménem CHAPS by měl být vyřešen až někdy v
> druhé půlce roku 2018, protože dobíhající smlouvy, vyhlášky apod. Do
> té doby máme to, co máme:
> - celostátní: ftp://ftp.cisjr.cz/ - vlaky jsou v Kangu, autobusy v
> JDF, obojí umím převádět do GTFS, bude na Githubu snad do konce roku
> - městská: co kdo dá, to je - Praha má GTFS volně, JMK pro nekomerční
> účely (ale prý se blýská na lepší časy), o dalších nevím
> - pražská live data z MHD: Nejjednodušší je odposlouchávat Tetra
> uplink (16 vysílačů na Prahu). DPP data nemá (protože outsourcing), to
> co je k dispozici například nemá čísla linek, které je potřeba
> dopočítávat z časů odjezdů z konečných. Autobusy, tramvaje a metro
> mají 3 různé IS, další dopraci něco centrálně posílají Ropidu. Mělo by
> se to ale zlepšovat a časem prý bude GTFS realtime.
>
> Licence pražských opendat: Pracuje se na tom, ale je to úředničina a
> tak se jim do toho moc nechce. Ale snad už se to konečně stane.
>
> Pražské modré zóny: Praha nevlastní všechny (díky Bémovi), takže není
> centrální registr, ale blýská se na lepší časy.
>
> Obecně zde mnohokrát zaznělo, že pokud máme zájem o nějaká opendata,
> tak se máme ozvat, aby byly zveřejněny prioritně a naopak pokud máme
> aplikaci využívající opendata, tak jim ji máme ukázat, ať mají čím
> přesvědčovat úřady pro uvolňování dalších dat.
>
> MSF
> Jethro
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz



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

Re: [Talk-it] Progetto Montagne Sicure

2016-11-07 Per discussione Alfredo Gattai

Ciao,

adottiamo anche noi ref:emergency= per i signpost.

Grazie a tutti per il contributo.

Alfredo


2016-11-05 17:47 GMT+01:00 Alfredo Gattai :

> Ah ah...si ho capito il concetto,,ma cozza abbastanza con la pratica. Di
> fatto e' lo stesso oggetto nel solito punto che ha due numeri..Non e' molto
> pratico fare due nodi ognuno con il suo ref, anche nel mondo della
> cartografia nautica si codificavano una volta le luci e le loro frequenze
> come oggetti separati sovrapposti sullo stesso punto poi si faceva un
> aggregato per distribuire il prodotto, poi si sono accorti che era meglio
> fare un unico oggetto con piu' attributidevo anche cercare di non
> complicare troppo la vita dei miei colleghi CAI e del Soccorso che devono
> imparare a mappare...
>
>
>
> 2016-11-05 17:32 GMT+01:00 Martin Koppenhoefer :
>
>>
>> 2016-11-05 17:23 GMT+01:00 Alfredo Gattai :
>>
>>> e' proprio questo il punto. Abbiamo sul terreno dei pali che hanno due
>>> numeri idendificativi, uno usato dall'ente che ha posizionato il palo e
>>> l'altro aggiuto sullo stesso palo usato da chi fa soccorso, oltre
>>> ovviamente le indicazioni dei percorsi, i tempi di percorrenza, etc.
>>> Non e' una cosa che deve accadere, e' gia' cosi'.
>>>
>>
>>
>> si, ma non vuol dire che in OSM devi mettere quindi per forza tutto su un
>> nodo. Vedilo cosÌ: stai mappando le targhe, non il palo. ;-)
>>
>>
>> Ciao,
>> Martin
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?