Re: [OSM-talk-be] [Tagging] area=yes on object without kind + using PICC & JOSM

[André Pirard]

On 2018-01-12 14:52, Jo wrote:
> You are right in that we shouldn't base any of our mapping on what is
> visible on Google Streetview. Which is why I was suggesting that
> somebody go check it out locally. I've been looking at Belgian aerial
> imagery we are allowed to use, taken over several years. But nothing
> useful can be seen on them either. What can be seen is that almost
> never more than 1 car was parked there when the planes flew over. So
> it's definitely not a parking lot.
>
> I don't think we really have a way to tag an empty piece of land with
> no defined "function" nor vegetation on it,
>
> Jo
I have overlaid OSM with the PICC (the digitalized version of those
aerial photographs).
The PICC shows nothing more than the road border.

The PICC has a 20cm precision, is extremely well done and we can trace
it (not to be confused with "copy").
I often *highly* recommend to use the PICC with JOSM in Wallonia.
In fact, I'm spending much time to use them to correct what is
neigbouring what I'm mapping.
Often, for example, the buildings are traced as roofs based on
imprecise, vague aerial photos.
PICC shows building bases instead, very cleverly and precisely
calculated from multiple photo angles.
And with Area Selector, one can trace a streetfull of houses in a single
click each, including numbers.
I've been asked why ID and Potlatch would be worse than JOSM.
I don't know. Just that when I meet something to leave as is, I know and
I can check that it's JOSM.
See my picture. It's Potlatch.
The "area" is offset 2 m on the right and 6 m on south.
The building is 5 m away from its place and it has no number 2.
The pedestrian crossings 2m and 5m, the wood on the right 6 m.
Etc ... Often, more complicated maps are simply horrifying.
The roads are mostly right but I believe that it's better to follow
PICC's way choices closely to show that PICC was used. And PICC does the
conversion of curved to straight lines for you.
Mistakes are sometimes easily corrected with JOSM's Improve Way
Accuracy, but it's harassing to spend much time doing that while other
mistakes continue to be made. And mapping a new house is much, much
faster than correcting a bad one.

*PLEASE, PLEASE* use PICC with JOSM in Wallonia !!!
Wallonia have lost 6 years while I was trying to have the SPW correct
their PICC server's mistake and I was helping JOSM to improve.
JOSM is not really difficult to use. Use it more ans more in parallel
with another software, which you can use when you're stuck until you
find out how to do it with JOSM. You will appreciate what more you can
do with JOSM.

Cheers
Cordialement,

André.




>
>
>
> 2018-01-12 14:38 GMT+01:00 José G Moya Y.  >:
>
> Please notice that, for doing something similar to what you do
> here (reading a lot of maps and aerial imaginery, being only one
> of them [3] google maps) I was forced to erase my edition and do
> it again.
> Just to warn you.
>
> El 12/1/2018 8:30, "Jo"  > escribió:
>
> It definitely doesn't look like a public parking lot. It would
> be good if someone local could resurvey if the shop is still
> in that house.
>
> Jo
>
> 2018-01-12 5:19 GMT+01:00 Marc Gemis  >:
>
> is there street view imagery ? do you have local knowledge ?
>
> If not, you might consider not fixing it. Yes it will be a
> useless
> polygon in the database, but isn't that better than
> changing it e.g.
> to a parking lot while it is a private property ?
>
> just my .5 cents
>
> m.
>
> On Fri, Jan 12, 2018 at 12:05 AM, OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com
> > wrote:
> > Hello,
> >
> > Osmose is complaining an area is mapped but not further
> specified: [1] and
> > [2]
> >
> > Here is how the place looks like: [3]
> >
> > I was thinking it's a side walk, but they're not to be
> mapped as area [4]
> > and the place doesn't really look like a square or plaza
> [5] nor like a
> > parking.
> >
> > How would you tag it ?
> >
> > Thx.
> >
> > [1] http://osmose.openstreetmap.fr/en/error/15140678368
> 
> > [2] https://www.openstreetmap.org/way/223853253
> 
> > [3] https://goo.gl/maps/yhA3rx2WVhM2
> 
> > [4] https://wiki.openstreetmap.org/wiki/Key:sidewalk
>

Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data

[Kathleen Lu]

>
> My argument is about the geometry information.  The friction map
> combines road geometries from OSM and Google road geometry information.
> I see no way it can be argued that this combination of road geometry
> data which is rendered into the friction map is a collective database.
> None of the four criteria of the collective database guideline is met
> (unless of course you postulate that OSM roads are a different type of
> feature than Google roads).
>
> What I'm saying is that road geometry is a different type of feature than
"distance-to-road" data. "Distance-to-road" would give you the distance to
the nearest road, it doesn't give you each separate road, and you couldn't
substitute that value for a real road network.


>
> Example:  You want to render a map with lakes supplementing the
> incomplete lake data from OSM with proprietary data from elsewhere.  So
> what you do is:
>
> * you take the lake geometries from OSM (equivalent to the OSM roads)
> * you create a distance-to-water function/API for you proprietary lake
> dataset (equivalent to the Google distance-to-road API)
> * you render both the OSM (based on the polygon geometries) and the
> proprietary data based lakes (based on the distance function) into your
> map (equivalent to the rendering of the friction map)
> * you enjoy your map showing lakes from both OSM and proprietary data
> without share-alike.
>


> Yes, depending on how you want to style your lakes doing so based on a
> distance function can be challenging - but that is just a minor hurdle.
>
> Your example doesn't work. Even if you could render "distance-to-water"
this way, you wouldn't get a set proprietary data based lakes + OSM lakes,
you would get a visualization of one massive complicated body of water that
included all oceans, rivers, streams, etc. (at the database level, it would
still be a bunch of data values, not a big polygon, plus the OSM polygons).
This doesn't sound minor to me at all, as that's a lot of data to process
(leaving aside that you'd have to have a distance-to-water API to pull
from, which would not be easy to get).


> Note from a business perspective as a data user i would not really mind
> if the above scenario was acceptable but as said it would practically
> mean the end of share-alike for map rendering applications - and that
> is likely not what the mappers who voted to adopt the ODbL had in mind.
>
> I disagree with the implications. Even stretching such a scenario to the
extremes as you describe above, I do not see a practical result that hurts
OSM. The visualization you described sounds really pointless. Sharealike or
not, why would someone go through this type of contortion to get an
approximate map rendering of water, with no labels for the proprietary
water areas? Such a map would look terrible.
If we look at actual use, the researchers added the assigned speed values
to calculate friction, which is useful for their research. The end result
does not in anyway substitute for an OSM road network, which is what we
should really be concerned with. I do not believe you'd presented a
realistic hypothetical that would really change OSM use and thus present a
true risk.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data

[Christoph Hormann]

On Friday 12 January 2018, Kathleen Lu wrote:
> Your analysis does not follow.
>
> The researcher's description says: "These datasets were each
> allocated a speed or speeds of travel in terms of time to cross each
> pixel of that type. The datasets were then combined to produce a
> 'friction surface'; a map where every pixel is allocated a nominal
> overall speed of travel based on the types occurring within that
> pixel."
>
> Thus, the "friction map" is calculated from first an assignment of a
> "speed to cross" property value to each road, railway, etc. This was
> a property value one added by the researchers, not one already in
> OSM. Thus, these principles from the collective database apply:
>
> [...]

My argument has nothing to do with the property (which could for the 
purpose of this simply be a constant value for all roads, i.e. a 
property containing no information at all).

My argument is about the geometry information.  The friction map 
combines road geometries from OSM and Google road geometry information.  
I see no way it can be argued that this combination of road geometry 
data which is rendered into the friction map is a collective database.  
None of the four criteria of the collective database guideline is met 
(unless of course you postulate that OSM roads are a different type of 
feature than Google roads).

You can also look at it from a different perspective:  If the mentioned 
use is compatible with the ODbL without share alike that would create a 
completely fool proof way of circumventing share-alike in map 
rendering.

Example:  You want to render a map with lakes supplementing the 
incomplete lake data from OSM with proprietary data from elsewhere.  So 
what you do is:

* you take the lake geometries from OSM (equivalent to the OSM roads)
* you create a distance-to-water function/API for you proprietary lake 
dataset (equivalent to the Google distance-to-road API)
* you render both the OSM (based on the polygon geometries) and the 
proprietary data based lakes (based on the distance function) into your 
map (equivalent to the rendering of the friction map)
* you enjoy your map showing lakes from both OSM and proprietary data 
without share-alike.

Yes, depending on how you want to style your lakes doing so based on a 
distance function can be challenging - but that is just a minor hurdle.

Note from a business perspective as a data user i would not really mind 
if the above scenario was acceptable but as said it would practically 
mean the end of share-alike for map rendering applications - and that 
is likely not what the mappers who voted to adopt the ODbL had in mind.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?

[Philippe Verdy]

Je pense qu'Osmose ne cherche pas que des "routes" et que les chemins
piétons sont appropriés aussi (highway=path), le but étant que les
bâtiments en question puissent être atteint et savoir quel est la plus
proche voirie utilisable ou localiser un parking même si on termine à pied.
C'est le chemin d'accès normal permettant ensuite de relier une entrée, un
point d'adresse, une boite à lettres, faire une livraison (éventuellement
par une voie privée et en franchissant une barrière ouverte à la demande).

Le 12 janvier 2018 à 19:06, Cédric Frayssinet  a
écrit :

> Bonsoir à tous,
>
> Je confirme que l'analyse est vraiment pertinente mais cela va être long
> d'en voir le bout ! Encore plus de 41 000 points à dégommer et cela prend
> du temps pour chacun d'eux.
>
> Je suis tombé dans ce quartier sur des squares indiqués sur le cadastre :
> http://www.openstreetmap.org/#map=18/45.81597/4.90275
>
> Comment tague-t-on cela si on veut que cela sorte de l'analyse, ce ne sont
> pas des routes...
>
> Merci d'avance,
>
> Cédric
>
>
>
> Le 08/01/2018 à 09:33, erwan salomon a écrit :
>
> Très bien cette analyse en effet
> pour le moment sur de l’urbain déjà bien à jour aucun faux positif
> des nouveau lotissement (enfin sur le cadastre de 2015 quand même) et des
> petits oublis
> je m’occupe de Lorient-Morbihan et je poursuivrais en m’éloignant
> progressivement
> par contre y’a du taff
> et quite à repérer des zone mal cartographié j’en profite pour faire du
> propre sur les voies, sinon on perd un bon repère
> du coup ça rallonge encore
> aller on dégomme du violet
>
> erwan [glyo]
>
> Le 6 janv. 2018 à 15:29, Christian Quest  a
> écrit :
>
> Un petit bilan après une bonne dizaine de jours...
>
> L'analyse comparant la voirie du cadastre avec OSM est fort intéressante !
>
> En zone urbaine, elle permet de détecter de petites impasses, des chemins,
> de nouveaux lotissements, etc.
> En zone plus rurale, elle est aussi intéressante même si elle remonte des
> chemins où le cadastre à prolongé le noms des rues, je pense souvent à tort.
>
> Je vous la recommande donc après plus d'une semaine d'usage régulier, elle
> ne m'a pas fait perdre de temps et trouvé des manques difficiles à détecter
> sans être sur le terrain.
>
> http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13
>
> Les principaux défauts sur les rond-points et places sont résolus... il
> n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne pas être
> détectés.
>
> --
> Christian Quest - OpenStreetMap France
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> En cure de désintoxication  de Google
> ! Client d'Enercoop ,
> l'énergie militante
>
> Également sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
>
> ___
> 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-legal-talk] Interesting use case of combining OSM with proprietary data

[Kathleen Lu]

They are using OSM road data and Google road data to generate what they
> call a "friction surface" which is essentially a raster map indicating
> how fast you can move at every point of the map - faster on roads,
> slower elsewhere depending on relief and landcover.  This friction map
> you can download on:
>
>
> https://map.ox.ac.uk/wp-content/uploads/accessibility/friction_surface_2015_v1.0.zip
>
> You can see in that map that they are using OSM road data and that they
> are also using data that is not in OSM.  Based on this friction map
> they are doing the accessability calculations.
>
> Of course it is possible that the OSM road data and the Google road data
> is available in different forms originally - as you write the wording
> indicates they have proximity information on the Google roads and not
> the actual geometry.  But they merge it to generate the friction map,
> for that it does not matter in what form the roads data exists, and i
> don't really see how you can argue this creates a collective database
> and not a derivative database - because if that is not a derivative
> database (combining two incomplete data sets to create a more complete
> data set to use) what is?
>
> Your analysis does not follow.
The researcher's description says: "These datasets were each allocated a
speed or speeds of travel in terms of time to cross each pixel of that
type. The datasets were then combined to produce a 'friction surface'; a
map where every pixel is allocated a nominal overall speed of travel based
on the types occurring within that pixel."

Thus, the "friction map" is calculated from first an assignment of a "speed
to cross" property value to each road, railway, etc. This was a property
value one added by the researchers, not one already in OSM. Thus, these
principles from the collective database apply:

   - the non-OSM data adds a particular type of geometry or data for a
   primary feature that was not already present within a regional cut, and the
   added feature data includes no OSM data; or


   - a non-OSM database replaces or adds a property of a primary feature,
   and uses either all OSM data or no OSM data for that property of that
   primary feature within the same regional cut (e.g., the URL property of the
   amenity=cafe primary feature is replaced by reference, using either all OSM
   data or no OSM data for the replacement URLs);

They state that datasets may be combined as long as there is no mixing of
an OSM data source with a non-OSM data source for a given
datatype/property. (It doesn't matter if the datasets can be thought of as
referencing each other because "the non-OSM and OSM datasets do not
reference each other" is only one of four examples the Guideline provides
of collective database circumstances.)

The Google distance-to-roads are not mixed with a OSM datatype. It's not
possible, as OSM doesn't have a distance-to-road datatype, and the Google
distance-to-road calculation is a calculation of the distance to the
nearest Google road, not the nearest OSM road.

The "speed to cross" value is also not an OSM data type. It is an entirely
new property that the researchers assigned to OSM road features based on
their own views of how "fast" a feature is. Whether the researchers also
assigned "speed to cross" properties to features from other datasets is
irrelevant, as those values didn't come from OSM.

The OSM road network + Google distance-to-road data + new assigned property
type "speed to cross" is the overall collective database the researchers
put together. They then performed calculations and analysis on this
database, including assigning a "friction" value to each pixel of a raster
map. That map I agree is a Produced Work, and it is a Produce Work built
from a Collective Database.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] Imagery_used = Custom

[Andreas Lattmann]

Ha, okay. 
Grazie mille!
Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-es] Importación de Catastro

[Javier Sánchez Portero]

Recomiendo usar la página de discusión de la propuesta para que creemos
entre todos una serie de preguntas y respuestas frecuentes.

https://wiki.openstreetmap.org/wiki/ES_talk:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios

Javier

El 12 de enero de 2018, 20:24, Javier Sánchez Portero 
escribió:

> Todo lo contrario Mateu, el programa coge de OSM los nombres de calles más
> aproximados al que viene en Catastro, luego se revisan a mano dando
> prioridad a lo que está en OSM. Respecto a los números de portal lo mismo.
> El trabajo que está hecho se respetará.
>
> Mira la propuesta en particular la guía de importación y gestión de
> proyectos. Te animo a liberar la importación en tu zona o a colaborar en el
> grupo que la lleve tu experiencia será muy útil.
>
> Saludos Javier
>
>
> El 12 ene. 2018 17:09, "Mateu Vic"  escribió:
>
> El tema de las denominaciones de las vías públicas me interesa
> especialmente y lo he trabajado bastante en campo, en gran parte de la isla
> de Mallorca y en algunas zonas de la península. ¿Supone la importación del
> catastro que las denominaciones ​tomadas sobre el terreno y contrastadas
> con el catastro, el callejero del censo electoral y/o distintas webs
> municipales quedarán sustituidas por la denominación (no siempre correcta)
> que figura en el catastro? ¿O hay manera de que la importación del catastro
> afecte solamente a aquellas vías públicas que no tienen aun denominación en
> OSM?
> Particularmente siempre he sido más partidario del trabajo "a pelo",
> elemento a elemento, que de las importaciones masivas: los bosques
> importados de Corine o los parajes-locality para mí son un ejemplo de lo
> que no debería hacerse en el mapa, puesto que ofrecen información inexacta
> y equívoca.
> Saludos
> mateuvic
>
>
> 
>  Libre
> de virus. www.avast.com
> 
> <#m_2204426743940197169_m_9175282467984264396_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2018-01-10 21:28 GMT+01:00 Javier Sánchez Portero :
>
>> Genial. No te preocupes, el trabajo se hará por partes.
>>
>> Ya he visto los avances en la validación. Gracias a los que están
>> participando.
>>
>> Yo tengo terminada, menos unos flecos, la propuesta. Estoy traduciendo al
>> inglés y espero remitir a imports la semana que viene.
>>
>> He leído los términos de uso de GitHub y no veo problema para subir
>> archivos de la importación, menos siendo temporal. Además hay varias formas
>> de subir archivos y no sería necesario usar ftp, que podría ser un problema
>> para algunos.
>>
>> Si no hay ninguna objeción, me gustaría *crear una cuenta en GitHub
>> anombre de osm-es*, para subir los archivos y el proyecto CatAtom2Osm,
>> para que no esté todo vinculado a mi nombre de usuario. El repositorio
>> serviría para que otros pudieran aportar software de interés para nuestra
>> comunidad.
>>
>> Saludos, Javier
>>
>> El 10 ene. 2018 18:51, "dcapillae"  escribió:
>>
>>> Hola, Javier.
>>>
>>> Me he apuntado para colaborar también como gestor de proyectos en los
>>> municipios limítrofes al municipio de Málaga. He pensado que si puedo
>>> ocuparme de Málaga ciudad, no me costará demasiado gestionar los
>>> proyectos
>>> de importación en los municipios de alrededor, que tienen bastantes menos
>>> edificios.
>>>
>>> https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%B1ol
>>> /Importaci%C3%B3n_de_edificios/Gu%C3%ADa_de_importaci%C3%B3n
>>> /Gesti%C3%B3n_de_proyectos#Pasos_previos
>>>
>>> Ya veremos si cuando empiecen a funcionar los proyectos puedo gestionar
>>> bien
>>> la importación en todos ellos, pero en principio creo que podría ocuparme
>>> del municipio de Málaga y de los municipios limítrofes a la capital.
>>>
>>>
>>>
>>>
>>> -
>>> Daniel Capilla
>>> OSM user: dcapillae
>>> --
>>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>>
>>> ___
>>> 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-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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Clifford Snow]

On Fri, Jan 12, 2018 at 9:59 AM, Stefan Keller  wrote:

> I would even go further by refering to policies about automated reply
> mails and/or chat bots. I can't find an authoritative source but I
> think there's at least a netiquette saying that communications to
> humans generated from machines should start by declaring it's a
> message from a machine.
>
> In this case my reaction also was that "I reviewed..." is misleading.
> I would propose s'thing like the following:
> ...
> Hello!
> This is a comment generated by #OSMCha:
> #REVIEWED_GOOD
> Thank you for your contributions to OpenStreetMap.
>

Another option would be to allow each of us to create our own "canned"
response.

A quick count shows something like 300,000+ edits by new mappers in 2017.
That would also include import accounts created in 2017 which inflates the
number. But it's still a large number. Ideally we would review more edits
by new mappers to help them get up to speed and offer words of
encouragement. Having tools like OSMCha really help. I've started employing
OSMCha late last year and find it helpful, especially being able to see
what was deleted.

Stefan - Thank you for offering a suggestion on how OSMCha can be improved.

Best,
Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tool for tag tracking

[Pierre Béland]

Thanks mmd and Roland, I was able to test it. 
Since these new queries extend the type of actions to report, 

Should there be a an action subtype that reports either tag or geometry only 
actions ?
det_action = [tag_create, tag_modify, tag_delete, geometry_create, 
geometry_modify, geometry_delete]
This new query on the test server reports action=deleted when and object is 
simply modified to remove all tags.See https://overpass-turbo.eu/s/uJ8
 
Pierre 
 

Le vendredi 12 janvier 2018 12:35:25 HNE, mmd  a écrit : 
 
 
 Am 12.01.2018 um 14:51 schrieb Pierre Béland:
> Hi Roland. Great additions again.
> 
> I cannot access https://dev.overpass-api.de/api_new_feat/ to test.
> 
> Hi have the message Forbidden, You don't have permission to access
> /api_new_feat/ on this server.
> 

Please disregard any line starting with "{{data:overpass,server". Those
are only needed for overpass turbo to know which Overpass server to use.
You should try one of the following query shortlinks as per Roland's
post instead:

https://overpass-turbo.eu/s/uF2
https://overpass-turbo.eu/s/uF4
https://overpass-turbo.eu/s/uF7
https://overpass-turbo.eu/s/uFa


-- 




___
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: [Talk-it] Imagery_used = Custom

[Andrea Albani]

Il changeset è relativo ad un evento Osm segnalato in lista un paio di
giorni fa da Alessandro Palmas. Hanno usato questo task

http://osmit-tm.wmflabs.org/project/29

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

Re: [Talk-es] Importación de Catastro

[Javier Sánchez Portero]

Todo lo contrario Mateu, el programa coge de OSM los nombres de calles más
aproximados al que viene en Catastro, luego se revisan a mano dando
prioridad a lo que está en OSM. Respecto a los números de portal lo mismo.
El trabajo que está hecho se respetará.

Mira la propuesta en particular la guía de importación y gestión de
proyectos. Te animo a liberar la importación en tu zona o a colaborar en el
grupo que la lleve tu experiencia será muy útil.

Saludos Javier

El 12 ene. 2018 17:09, "Mateu Vic"  escribió:

El tema de las denominaciones de las vías públicas me interesa
especialmente y lo he trabajado bastante en campo, en gran parte de la isla
de Mallorca y en algunas zonas de la península. ¿Supone la importación del
catastro que las denominaciones ​tomadas sobre el terreno y contrastadas
con el catastro, el callejero del censo electoral y/o distintas webs
municipales quedarán sustituidas por la denominación (no siempre correcta)
que figura en el catastro? ¿O hay manera de que la importación del catastro
afecte solamente a aquellas vías públicas que no tienen aun denominación en
OSM?
Particularmente siempre he sido más partidario del trabajo "a pelo",
elemento a elemento, que de las importaciones masivas: los bosques
importados de Corine o los parajes-locality para mí son un ejemplo de lo
que no debería hacerse en el mapa, puesto que ofrecen información inexacta
y equívoca.
Saludos
mateuvic


Libre
de virus. www.avast.com

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

2018-01-10 21:28 GMT+01:00 Javier Sánchez Portero :

> Genial. No te preocupes, el trabajo se hará por partes.
>
> Ya he visto los avances en la validación. Gracias a los que están
> participando.
>
> Yo tengo terminada, menos unos flecos, la propuesta. Estoy traduciendo al
> inglés y espero remitir a imports la semana que viene.
>
> He leído los términos de uso de GitHub y no veo problema para subir
> archivos de la importación, menos siendo temporal. Además hay varias formas
> de subir archivos y no sería necesario usar ftp, que podría ser un problema
> para algunos.
>
> Si no hay ninguna objeción, me gustaría *crear una cuenta en GitHub
> anombre de osm-es*, para subir los archivos y el proyecto CatAtom2Osm,
> para que no esté todo vinculado a mi nombre de usuario. El repositorio
> serviría para que otros pudieran aportar software de interés para nuestra
> comunidad.
>
> Saludos, Javier
>
> El 10 ene. 2018 18:51, "dcapillae"  escribió:
>
>> Hola, Javier.
>>
>> Me he apuntado para colaborar también como gestor de proyectos en los
>> municipios limítrofes al municipio de Málaga. He pensado que si puedo
>> ocuparme de Málaga ciudad, no me costará demasiado gestionar los proyectos
>> de importación en los municipios de alrededor, que tienen bastantes menos
>> edificios.
>>
>> https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%B1ol
>> /Importaci%C3%B3n_de_edificios/Gu%C3%ADa_de_importaci%C3%B3n
>> /Gesti%C3%B3n_de_proyectos#Pasos_previos
>>
>> Ya veremos si cuando empiecen a funcionar los proyectos puedo gestionar
>> bien
>> la importación en todos ellos, pero en principio creo que podría ocuparme
>> del municipio de Málaga y de los municipios limítrofes a la capital.
>>
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> 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-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

Re: [OSM-talk-fr] réflexion sur l'ia appliqué aux cartes

[marc marc]

Un exemple pratique pour osm
https://github.com/geometalab/OSMDeepOD

résultat repris par un maproulette qui signale les passages piéton 
manquant http://maproulette.org/map/1416/1233235
Le taux de réussite est très variable. il aurait peut-être fallu 
entraîner la reconnaissance plus localement pour tenir compte des 
différences (ex en ville, il y a parfois des zones hachurées pour 
désigner la fin d'une bande de circulation, l'ia s'y trompe).
Mais l'idée est bluffante.

il ne manquerait plus qu'une interface style opensolarmap ou 
http://audit.osmz.ru/browse/demo/NVDS353-12038415
pour confirmer en un clic si c'est réellement ou pas un passage piéton.

j'imagine un pas + loin : une app dans la voiture qui compare osm et la 
réalité, à la fin du trajet il te signale les panneaux qui ont changé.
ce serrait idéal pour maintenir osm à jour.

Le 28. 12. 17 à 15:36, Vincent Frison a écrit :
> Article très intéressant !
> 
> Comme l'auteur je me demande quelle est la relation entre la technique 
> leur permettant d'avoir des modèles full 3D des villes lorsqu'on est en 
> mode satellite/3D et celle leur permettant d'avoir des empreintes de 
> bâtiments extrêmement précises (+ infos de hauteur visiblement) 
> lorsqu'on en mode carte / par défaut.
> 
> Mais dans le 1er cas c'est clairement fait avec de la photogrammétrie 
> alors que dans le 2e cas l'auteur laisse penser que les algos de Google 
> se seraient basés des images ariennes standards... ce qui me semble peu 
> probable. A mon avis ils font d'abord de la photogrammétrie, et une fois 
> qu'ils ont leur modèle 3D ils peuvent (re)dessiner les bâtiments pour le 
> mode carte / par défaut.
> 
> 
> Le 25 décembre 2017 à 15:32,  > a écrit :
> 
> Autant l'exemple de Christian est bon (on peut détecter non
> seulement la forme mais aussi l'encombrement - un toit plat incliné
> vers le sud est idéal mais s'il est occupé par des cheminées et
> autres antennes, il est moins utilisable pour du solaire), autant
> l'exemple de Google alourdit la carte.
> 
> Déjà nos empreintes de bâtiments sont la moitié de la base.
> 
> Dans l'article de Google ils disent que ça permet de reconnaître
> plus facilement un bâtiment. Exact. Sauf qu'il ne faut le faire que
> pour les bâtiments remarquables et mettre en avant les traits
> remarquables.
> 
> J'entends pour de la cartographie. Par exemple quand Google détecte
> une parabole sur un bâtiment, c'est utile si ça permet de le repérer
> parmi 10 bâtiments identiques, sinon c'est sans intérêt pour la
> quasi totalité des utilisateurs et apportera plus un bruit de fond
> (aussi un aspect réaliste pour une simulation 3D).
> 
> De même on trace les routes, on ne les dessine pas (avoir la largeur
> de la route n'est pas inutile, par contre le détail importe peu et
> peu nuire à la lisibilité : un bon livre d'ornithologie dessine des
> caractéristiques de l'oiseau et ne donne pas une photo de l'animal).
> 
> Bon, super, avec de l'IA je fais un programme qui ajoute
> surface=aslphat sur des routes en fonction de la couleur et hop,
> plein de bitcoins sur mon compte.
> 
> Donc IA oui, mais à bon escient.
> 
> 
>          /\
> 
>    /__\
> 
>      /\
> 
>    /__\
> 
> /\
> 
>     |_|
> 
> Ceci n'est pas un sapin ;-)
> 
> Jean-Yvon
> 
> 
> Le 24/12/2017 à 10:15, François Lacombe - fl.infosrese...@gmail.com
>  a écrit :
>> Bonjour
>>
>> Je partage également votre avis, les techniques d'apprentissage
>> permettraient aussi de détecter les biais dans l'utilisation des tags.
>> Surtout signaler à l'utilisateur que certaines combinaisons sont
>> peu utilisées en proportion à l'utilisation des clés concernées
>> donc probablement erronées  (building + man_made=street_cabinet
>> par ex)
>>
>> Ca permettrait de faciliter le travail de developpelent d'osmose
>>
>> My 2 cents
>>
>> François
>>
>> Le 23 déc. 2017 1:15 PM, "Martin Noblecourt"
>> > a écrit :
>>
>> Tout à fait d'accord avec Christian !
>>
>> Les initiatives se multiplient de télédétection automatique,
>> l'enjeu va être une intégration harmonieuse avec la base de
>> données et la culture OSM existante, donc forcément avec une
>> intervention humaine pour contrôler/harmoniser.
>>
>> Côté CartONG on a plusieurs petites expérimentations dans les
>> tuyaux (pré-reconnaissance automatique des zones
>> résidentielles avant validation humaine notamment), si des
>> gens sont intéressés pour aider nos bénévoles là dessus,
>> n'hésitez pas à me contacter ;-)
>>
>> Joyeux Noël à tous !
>>
>> Martin
>>
>>
>> On 23/12/2017 13:00, 

[Talk-it] Imagery_used = Custom

[Andreas Lattmann]

Buongiorno,
Ne sapete qualche cosa di queste mappe citate in questo changeset [1]?
Grazie.

[1] https://www.openstreetmap.org/changeset/55354965

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk] Tool for tag tracking

[Marco]

Wow, that's nice, thanks!


Il 12/01/2018 06:31, Roland Olbricht ha scritto:

Hi,

for the sake of completeness, I would like to give a preview what is 
in the development for Overpass API:


Similar to this one

https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass 



you could nowadays search with https://overpass-turbo.eu/s/uF0
for all highways that have changed since the beginning of the year in 
and around Antwerp:


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
out geom;

I suggest the "out geom" mode over recursing to the nodes. Overpass 
Turbo can handle both, but the "out geom" means that there is exactly 
one item per object in question. No unchanged nodes get involved.


The above result is bloated by objects like
https://www.openstreetmap.org/way/469659128/history
It has no change to its highway value but just lost the unrelated tag 
"horse=no".


Here comes a feature in the staging area for the next version into 
play. We do not ask for all changes but just for changes that affect 
the tag "highway": https://overpass-turbo.eu/s/uF2


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:t[highway]);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

The line "compare(delta:t[highway]);" reads as: keep only objects that 
have changed in the value "t[highway]". The last line is a directive 
to execute the query on the development server.


We could even drill down further and retrieve only objects that have 
been created or deleted: https://overpass-turbo.eu/s/uF4


[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

This is admittedly hacky and the final implementation might have a 
more straightforward term. The condition for "compare" always 
evaluates to the empty string for non-existing objects. And for 
existing objects to "0" as we just have specified, hence it can tell 
apart existing from non-existing objects.


Can we separate the deleted from the created objects? Yes,
https://overpass-turbo.eu/s/uF7 delivers only created objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  way._(newer:"2018-01-01T00:00:01Z");
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

And https://overpass-turbo.eu/s/uFa delivers only deleted objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

Please note that these are not yet in a published release because 
there may come up a reason to change the syntax. If that happens, I 
will write a mail here again. For example, it might be more concise to 
do these tasks with a three argument "changed" condition. But I have 
not evaluated yet whether this leads to a logically sound syntax.


Best regards,
Roland


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



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

[Talk-cz] Starva iD editor - chyba

[Milan Cerny]

Ahoj, přestalo fungovat ukládání v Strava iD editoru. Dnes už jsem zmařil dva 
hodinové changesety. Ach jo... 
Normálním iD funguje jak má, Strava běží normálně ale při uložení hlásí chybu 
"není internetové připojení"
Neměl by někdo typ jak lokálně uložit neuložená data z iD editoru? Případně 
jestli se to dá odněkud vytáhnout, cache, temp... (chrome / W10)

Díky za případnou pomoc.

Milan

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

Re: [Talk-GB] AGM planning task force

[Philip Barnes]

Manchester certainly sounds a good choice.

As for venues I would suggest The Manchester Escalator (open working
space) on Deansgate, walkable from the stations.

I attended a Manchester Open Data Group meeting there, on behalf of
OSM, a couple of years ago and think it is a suitable venue with lots
of options and we can no doubt get advice fro the open data people.

The website is http://centralworking.com/locations/manchester

Phil (trigpoint)

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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Frederik Ramm]

Hi,

On 01/12/2018 05:08 PM, Colin Smale wrote:
> I haven't yet heard what the intention of these edits is. It seems to be
> to split waterways at all junctions with other waterways, 

This is something that any routing engine for a road network must do -
and thankfully it is usually done in the prepare-data-for-routing step
and not on OSM! Maybe whatever the use case is here, the user can take a
cue (or even code) from such preprocessing.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Challenge ? Si on dégommait du rose ?

[Cédric Frayssinet]

Bonsoir à tous,

Je confirme que l'analyse est vraiment pertinente mais cela va être long
d'en voir le bout ! Encore plus de 41 000 points à dégommer et cela
prend du temps pour chacun d'eux.

Je suis tombé dans ce quartier sur des squares indiqués sur le cadastre
: http://www.openstreetmap.org/#map=18/45.81597/4.90275

Comment tague-t-on cela si on veut que cela sorte de l'analyse, ce ne
sont pas des routes...

Merci d'avance,

Cédric


Le 08/01/2018 à 09:33, erwan salomon a écrit :
> Très bien cette analyse en effet
> pour le moment sur de l’urbain déjà bien à jour aucun faux positif
> des nouveau lotissement (enfin sur le cadastre de 2015 quand même) et
> des petits oublis
> je m’occupe de Lorient-Morbihan et je poursuivrais en m’éloignant
> progressivement
> par contre y’a du taff
> et quite à repérer des zone mal cartographié j’en profite pour faire
> du propre sur les voies, sinon on perd un bon repère
> du coup ça rallonge encore
> aller on dégomme du violet
>
> erwan [glyo]
>
>> Le 6 janv. 2018 à 15:29, Christian Quest > > a écrit :
>>
>> Un petit bilan après une bonne dizaine de jours...
>>
>> L'analyse comparant la voirie du cadastre avec OSM est fort
>> intéressante !
>>
>> En zone urbaine, elle permet de détecter de petites impasses, des
>> chemins, de nouveaux lotissements, etc.
>> En zone plus rurale, elle est aussi intéressante même si elle remonte
>> des chemins où le cadastre à prolongé le noms des rues, je pense
>> souvent à tort.
>>
>> Je vous la recommande donc après plus d'une semaine d'usage régulier,
>> elle ne m'a pas fait perdre de temps et trouvé des manques difficiles
>> à détecter sans être sur le terrain.
>>
>> http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=13
>> 
>>
>> Les principaux défauts sur les rond-points et places sont résolus...
>> il n'y a que les grands rond-points tronçonnés (beurk) qui peuvent ne
>> pas être détectés.
>>
>> -- 
>> Christian Quest - OpenStreetMap France
>> ___
>> 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


-- 
En cure de désintoxication  de
Google ! Client d'Enercoop
, l'énergie militante

Également sur Mastodon : @bristow...@framapiaf.org


Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Stefan Keller]

2018-01-12 17:01 GMT+01:00 Tobias Knerr :
> I agree. Right now, messages and comments sent via OSM channels tend to
> be written by humans for a specific individual recipient, which gives
> them a very good signal-to-noise ratio.

Interesting discussion to me because I'm working on a tool that
enhances onosm.org and generates OSM notes and messages to inbox when
an OSM object has been modified. I think it should be allowed to send
auto-generated messages to OSM channels as long as it's fair use or if
one can opt-out (in case of "personal" comments).

> Subjectively, I also tend to find it a bit off-putting when canned
> messages try to imitate human writing. Compared to obviously automated

I would even go further by refering to policies about automated reply
mails and/or chat bots. I can't find an authoritative source but I
think there's at least a netiquette saying that communications to
humans generated from machines should start by declaring it's a
message from a machine.

In this case my reaction also was that "I reviewed..." is misleading.
I would propose s'thing like the following:
...
Hello!
This is a comment generated by #OSMCha:
#REVIEWED_GOOD
Thank you for your contributions to OpenStreetMap.
...

If the reviewer can edit the text before it's being send by OSMCha
(under the name of the user), then it's a kind of mixed "authorship"
and yet another case.

:Stefan

[0]: https://github.com/mapbox/osmcha-frontend/issues/248


2018-01-12 17:01 GMT+01:00 Tobias Knerr :
> On 12.01.2018 15:39, Andy Townsend wrote:
>> More seriously, any automatic use of OSM messages is problematical
>> because it devalues the messages that we want people to actually read -
>> the ones that are composed by and sent be a human, and have actual
>> useful information in them
>
> I agree. Right now, messages and comments sent via OSM channels tend to
> be written by humans for a specific individual recipient, which gives
> them a very good signal-to-noise ratio. I enjoy that a lot and would
> like to keep things that way.
>
> Subjectively, I also tend to find it a bit off-putting when canned
> messages try to imitate human writing. Compared to obviously automated
> messages ("your changeset was reviewed by user X"), they can feel
> somewhat dishonest. I accept that people will feel differently about
> this, though.
>
> ___
> 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] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

Am 2018-01-12 um 17:01 schrieb Tobias Knerr:
> On 12.01.2018 15:39, Andy Townsend wrote:
>> More seriously, any automatic use of OSM messages is problematical
>> because it devalues the messages that we want people to actually read -
>> the ones that are composed by and sent be a human, and have actual
>> useful information in them
> 
> I agree. Right now, messages and comments sent via OSM channels tend to
> be written by humans for a specific individual recipient, which gives
> them a very good signal-to-noise ratio. I enjoy that a lot and would
> like to keep things that way.

We could introduce a special kind of changeset discussion comment which
does trigger email notification. Any comment which is automatically
generated should be such a "silent comment".

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-at] Wiener Kurzparkzonen

[Gabriel]

Diese Fehlermeldung wurde durch die App "Free Parking" (
https://play.google.com/store/apps/details?id=fr.lcdm.freeparking )
kreiert, bevor man nun einen tag "erfindet" könnte man evt nachfragen wie
die das "free parking" auswerten, die App gibt es ja für mehr Städte wie
haben andere es gelöst? (nur als Idee.)
Die App hat aber nur ca 1.000 Bewertungen also kann man auch mM auch darauf
verzichten.

Am 12. Januar 2018 um 17:38 schrieb Andreas :

> Am 2018-01-12 um 16:19 schrieb Stefan Nagy:
> > Hallo,
> >
> > ich habe gerade einen Fehlerbericht (note) gelesen, bei dem es um eine
> > Parkmöglichkeit in Wien geht (siehe
> > https://www.openstreetmap.org/note/1264962). Wenn ich das richtig
> > interpretiere, dann geht es hier um das Vorhandensein eines
> > Parkstreifens (also der Parkmöglichkeiten auf der Straße) und darum,
> > dass das Parken hier etwas kostet – weil wir uns da in einer Wiener
> > Kurzparkzone befinden.
> >
> > Hier geht es mir jetzt nicht um den konkreten Fehlerbericht, sondern um
> > eine allgemeine Frage: Kann man als Ziel definieren, dass wir mit
> > parking:lane in Wien die Parkmöglichkeiten auf den Straßen eintragen und
> > dabei die parking:condition-Attribute setzen, je nachdem, ob sich eine
> > Straße in einer Kurzparkzone befindet? Spricht da irgendwas dagegen bzw.
> > fallen euch bessere Möglichkeiten ein, die Kurzparkzonen zu mappen?
>
> Finde es interessant, dass im Wiki keine Empfehlungen für Kurzparkzonen
> existieren.
>
> Die Frage ist, was du bei "parking:condition" für Attribute setzen
> willst? Nur den Hinweis auf Kurzparkzone Wien oder bei jeder
> parking:lane immer brav in welcher Zeit das Parken kostenpflichtig ist?
>
> lg Andreas
> alias geologist
>
> >
> > Beste Grüße,
> > Stefan.
> >
> >
> >
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Wiener Kurzparkzonen

[Stefan Nagy]

--
E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/

Am 12.01.2018 17:38 schrieb Andreas:

Am 2018-01-12 um 16:19 schrieb Stefan Nagy:

...
Hier geht es mir jetzt nicht um den konkreten Fehlerbericht, sondern 
um

eine allgemeine Frage: Kann man als Ziel definieren, dass wir mit
parking:lane in Wien die Parkmöglichkeiten auf den Straßen eintragen 
und

dabei die parking:condition-Attribute setzen, je nachdem, ob sich eine
Straße in einer Kurzparkzone befindet? Spricht da irgendwas dagegen 
bzw.

fallen euch bessere Möglichkeiten ein, die Kurzparkzonen zu mappen?


Finde es interessant, dass im Wiki keine Empfehlungen für Kurzparkzonen
existieren.

Die Frage ist, was du bei "parking:condition" für Attribute setzen
willst? Nur den Hinweis auf Kurzparkzone Wien oder bei jeder
parking:lane immer brav in welcher Zeit das Parken kostenpflichtig ist?


Gute Frage… Ich tendiere zu impliziten Werten mit einer Dokumentation im 
Wiki –
hab aber viel zu wenig Erfahrung bei OSM um diesen Standpunkt mit 
Inbrunst

verteidigen zu können oder zu wollen.

Soweit ich auf den Seiten der Stadt Wien sehe gibt es drei verschiedene 
Arten

von Kurzparkzonen in Wien, die wären bei impliziten Werten jedenfalls zu
unterscheiden.

LG,
Stefan.

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

Re: [OSM-talk] Tool for tag tracking

[mmd]

Am 12.01.2018 um 14:51 schrieb Pierre Béland:
> Hi Roland. Great additions again.
> 
> I cannot access https://dev.overpass-api.de/api_new_feat/ to test.
> 
> Hi have the message Forbidden, You don't have permission to access
> /api_new_feat/ on this server.
> 

Please disregard any line starting with "{{data:overpass,server". Those
are only needed for overpass turbo to know which Overpass server to use.
You should try one of the following query shortlinks as per Roland's
post instead:

https://overpass-turbo.eu/s/uF2
https://overpass-turbo.eu/s/uF4
https://overpass-turbo.eu/s/uF7
https://overpass-turbo.eu/s/uFa


-- 




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

Re: [Talk-it] Bacheche pubbliche

[liste DOT girarsi AT posteo DOT eu]

Il 12/01/2018 13:56, Cascafico Giovanni ha scritto:

Tempo fa si era parlato di quella per i necrologi e, durante la
discussione, era uscita anche una possibile definizione generica con la
coppia di tag:

tourism=information
information=board

Credo che questo tipo di PDI non sia così marginale., per cui vi chiedo se
c'è un'alternativa, visto che le bacheche per annunci istituzionali (ma
anche dei film al cinema) non sono poi così a loro agio nel gruppo
"tourism" [1].



Per completezza la discussione è questa:

http://gis.19327.n8.nabble.com/Tag-bacheca-necrologi-td5904721.html#a5904960

E sempre per completezza si diceva una cosa simile alla fine:

information=board
board_type=obituary (nel caso necrologio)


In aggiunta la mia opinione, sembra ormai chiaro che alcuni tipi di 
informazioni board sono per conto suo, è il caso di orientarci su un 
tipo di informazione pubblicitaria, con conseguente taggatura?


Quindi un probabile tag advertising [0]?

Magari, come ho mappato una tabella in legno, riportante il nome di un 
B, al simile con questi tag:


man_made=advertising
advertising=board/poster_box
board_type=obituary/notice (necrologio, evento festivo/pubblicitario)

Di fatto sono informazioni di avviso non ufficiali, ma solo per 
incuriosire o informare dell'evento funesto, come nel caso del necrologio.


[0] https://wiki.openstreetmap.org/wiki/Key:advertising



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-es] Importación de Catastro

[Mateu Vic]

El tema de las denominaciones de las vías públicas me interesa
especialmente y lo he trabajado bastante en campo, en gran parte de la isla
de Mallorca y en algunas zonas de la península. ¿Supone la importación del
catastro que las denominaciones ​tomadas sobre el terreno y contrastadas
con el catastro, el callejero del censo electoral y/o distintas webs
municipales quedarán sustituidas por la denominación (no siempre correcta)
que figura en el catastro? ¿O hay manera de que la importación del catastro
afecte solamente a aquellas vías públicas que no tienen aun denominación en
OSM?
Particularmente siempre he sido más partidario del trabajo "a pelo",
elemento a elemento, que de las importaciones masivas: los bosques
importados de Corine o los parajes-locality para mí son un ejemplo de lo
que no debería hacerse en el mapa, puesto que ofrecen información inexacta
y equívoca.
Saludos
mateuvic


Libre
de virus. www.avast.com

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

2018-01-10 21:28 GMT+01:00 Javier Sánchez Portero :

> Genial. No te preocupes, el trabajo se hará por partes.
>
> Ya he visto los avances en la validación. Gracias a los que están
> participando.
>
> Yo tengo terminada, menos unos flecos, la propuesta. Estoy traduciendo al
> inglés y espero remitir a imports la semana que viene.
>
> He leído los términos de uso de GitHub y no veo problema para subir
> archivos de la importación, menos siendo temporal. Además hay varias formas
> de subir archivos y no sería necesario usar ftp, que podría ser un problema
> para algunos.
>
> Si no hay ninguna objeción, me gustaría *crear una cuenta en GitHub
> anombre de osm-es*, para subir los archivos y el proyecto CatAtom2Osm,
> para que no esté todo vinculado a mi nombre de usuario. El repositorio
> serviría para que otros pudieran aportar software de interés para nuestra
> comunidad.
>
> Saludos, Javier
>
> El 10 ene. 2018 18:51, "dcapillae"  escribió:
>
>> Hola, Javier.
>>
>> Me he apuntado para colaborar también como gestor de proyectos en los
>> municipios limítrofes al municipio de Málaga. He pensado que si puedo
>> ocuparme de Málaga ciudad, no me costará demasiado gestionar los proyectos
>> de importación en los municipios de alrededor, que tienen bastantes menos
>> edificios.
>>
>> https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%B1ol
>> /Importaci%C3%B3n_de_edificios/Gu%C3%ADa_de_importaci%C3%B3n
>> /Gesti%C3%B3n_de_proyectos#Pasos_previos
>>
>> Ya veremos si cuando empiecen a funcionar los proyectos puedo gestionar
>> bien
>> la importación en todos ellos, pero en principio creo que podría ocuparme
>> del municipio de Málaga y de los municipios limítrofes a la capital.
>>
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> 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-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-talk-be] upcoming events: Brussels, Hasselt, Louvain-la-Neuve, Arlon, ...

[joost schouppe]

Hi,

Of course we hope to see you at Open Belgium, but there's also:

- FOSDEM, a huge open source event in Brussels (3/4 Februsary):
https://fosdem.org/2018/

- a Road Completion mapping workshop, where we want to work on the
thousands of missing roads we found with AIV data. It's beginner-friendly,
but there's also work for advanced mappers. Feb 27th, Brussels. Info:
https://www.meetup.com/OpenStreetMap-Belgium/events/246749702/
We would like to do this all around Flanders too, so let us know if you
have an idea for a place to do this.

- we'll have informal meetups in Brussel, Hasselt and Arlon in the coming
months. As always, you can propose a meetup near you and we'll send some
support! For an overview:
https://www.meetup.com/OpenStreetMap-Belgium/events/

Apart from meetup, you can also follow our events through
http://www.osm.be/calendar.html or http://maptime.io/belgium/

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

Re: [Talk-at] Wiener Kurzparkzonen

[Andreas]

Am 2018-01-12 um 16:19 schrieb Stefan Nagy:
> Hallo,
> 
> ich habe gerade einen Fehlerbericht (note) gelesen, bei dem es um eine
> Parkmöglichkeit in Wien geht (siehe
> https://www.openstreetmap.org/note/1264962). Wenn ich das richtig
> interpretiere, dann geht es hier um das Vorhandensein eines
> Parkstreifens (also der Parkmöglichkeiten auf der Straße) und darum,
> dass das Parken hier etwas kostet – weil wir uns da in einer Wiener
> Kurzparkzone befinden.
> 
> Hier geht es mir jetzt nicht um den konkreten Fehlerbericht, sondern um
> eine allgemeine Frage: Kann man als Ziel definieren, dass wir mit
> parking:lane in Wien die Parkmöglichkeiten auf den Straßen eintragen und
> dabei die parking:condition-Attribute setzen, je nachdem, ob sich eine
> Straße in einer Kurzparkzone befindet? Spricht da irgendwas dagegen bzw.
> fallen euch bessere Möglichkeiten ein, die Kurzparkzonen zu mappen?

Finde es interessant, dass im Wiki keine Empfehlungen für Kurzparkzonen
existieren.

Die Frage ist, was du bei "parking:condition" für Attribute setzen
willst? Nur den Hinweis auf Kurzparkzone Wien oder bei jeder
parking:lane immer brav in welcher Zeit das Parken kostenpflichtig ist?

lg Andreas
alias geologist

> 
> Beste Grüße,
> Stefan.
> 
> 
> 


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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Jez Nicholson]

"Improve river network topology"... That would be for water flow modelling.

On Fri, 12 Jan 2018 16:10 Colin Smale,  wrote:

> User hornbydd2 has been making large numbers of edits to waterways in the
> UK which have created loads of problems in relations, including admin
> boundaries.
>
> I haven't yet heard what the intention of these edits is. It seems to be
> to split waterways at all junctions with other waterways, e.g. where a
> stream joins a main flow. In any case the splits are causing the problem:
> the tags on the way get copied over, but the relation memberships are not.
> Net result is a whole bunch of broken relations. I think they are
> considering how to fix up the damage, but I feel a revert may be the path
> of least resistance...
>
> I started a discussion about one changeset, but I now see the issue goes
> much further, both geographically and in terms of the types of objects
> which may be impacted:
>
> https://www.openstreetmap.org/changeset/55377588#
>
> Regards,
>
> Colin
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Heads up: Please check recent edits by this user...

[Colin Smale]

User hornbydd2 has been making large numbers of edits to waterways in
the UK which have created loads of problems in relations, including
admin boundaries. 

I haven't yet heard what the intention of these edits is. It seems to be
to split waterways at all junctions with other waterways, e.g. where a
stream joins a main flow. In any case the splits are causing the
problem: the tags on the way get copied over, but the relation
memberships are not. Net result is a whole bunch of broken relations. I
think they are considering how to fix up the damage, but I feel a revert
may be the path of least resistance... 

I started a discussion about one changeset, but I now see the issue goes
much further, both geographically and in terms of the types of objects
which may be impacted: 

https://www.openstreetmap.org/changeset/55377588# 

Regards, 

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Tobias Knerr]

On 12.01.2018 15:39, Andy Townsend wrote:
> More seriously, any automatic use of OSM messages is problematical
> because it devalues the messages that we want people to actually read -
> the ones that are composed by and sent be a human, and have actual
> useful information in them

I agree. Right now, messages and comments sent via OSM channels tend to
be written by humans for a specific individual recipient, which gives
them a very good signal-to-noise ratio. I enjoy that a lot and would
like to keep things that way.

Subjectively, I also tend to find it a bit off-putting when canned
messages try to imitate human writing. Compared to obviously automated
messages ("your changeset was reviewed by user X"), they can feel
somewhat dishonest. I accept that people will feel differently about
this, though.

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

Re: [OSM-talk] Fwd: Automatically generated changeset discussion comments by OSMCha

[Clifford Snow]

I echo Bryan - this is a much needed feature. I started incorporating
OSMCha into my review of new users in my area. That I could easily capture
"good and bad" edits and post a comment to the user at the same time is
nice. When I do come across a bad edit, and it doesn't happen often, I post
a more complete changeset message. For example, a yesterday a new user made
one bad and one good edit. The bad edit was to add a natural=water
rectangle in a back yard, his I'm assuming. It was so large you could fit
two or more olympic sized swimming pools in the same area. The other edit
was to add a parking lot. I often even post tips when they make a good edit
but the edit could use some improvement - often squaring houses.

OSMCha offers us the chance to catch problems early which is going to
discourage vandalism by removing any trace of it. That way the new user
can't show their friends how they added say a pokemon spawning feature next
to their house.

Willie - thanks for the feature

Clifford

On Fri, Jan 12, 2018 at 6:17 AM, Erwin Olario  wrote:

>
> reposting an earlier reply, which i mistakenly sent directly just to
> Michael
> -- Forwarded message -
> From: Erwin Olario 
> Date: Fri, Jan 12, 2018 at 10:15 PM
> Subject: Re: [OSM-talk] Automatically generated changeset discussion
> comments by OSMCha
> To: Michael Reichert 
>
>
> I believe it's a good idea. At present, any OSM user (and all OsmCha
> users, are OSM users) can leave any comment to a changeset, whether or not
> the mapper asked for any.
>
> Earlier, I filed a ticket to enhance OsmCha behavior. Instead of posting a
> default message, the reviewer should leave details outlining how the
> changeset could be improved (or why they think it's bad.)
>
> [0]: https://github.com/mapbox/osmcha-frontend/issues/248
>
> On Fri, Jan 12, 2018 at 10:10 PM Michael Reichert 
> wrote:
>
>> Hi,
>>
>> OSMCha started posting comments to changesets a few days ago when a user
>> marks a changeset as good or bad.
>> https://www.openstreetmap.org/user/wille/diary/43101
>> I would like to ask the author(s) of OSMCha to disable this feature.
>>
>> We expect to read all mappers incoming message (personal messages and
>> changeset comments). If third-party tools start to post comments to lots
>> of changesets automatically, this is some kind of spamming. If OSM sends
>> to much emails to a user, the user will probably ignore them or treat
>> them as spam.
>>
>> I think that OSMCha should not post a comment automatically except if
>> the user has explicitly asked for feedback or there are quality issues
>> regarding the edit (mistakes, vandalism, guideline violations or
>> anything else which makes it necessary to talk to the user).
>>
>> I post this email to this mailing list instead of filing a bug report a
>> Github [1] because I want to bring this problem to the wider audience
>> and initiate a general discussion on the acceptable usage of the
>> changeset comments API.
>>
>> What are your thoughts and opinions on this issue?
>>
>> Best regards
>>
>> Michael
>>
>>
>> [1] Btw, which Github repository would be the correct one the file the
>> bug report at?
>> https://duckduckgo.com/?q=osmcha+github=ffsb=web
>>
>>
>> --
>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>> ausgenommen)
>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Andy Townsend]

On 12/01/2018 14:52, Bryan Housel wrote:

- “To European eyes the comments look like they were written by a six-year-old”


Be nice everyone!


Bryan, this is "being nice" in English.  It's a reply that incorporates 
a certain amount of humour (quotes around sarcasm, link to 
not-entirely-serious article containing an example where "Punctuation 
saves lives", smiley at the end).  It's an attempt to say that yes, 
there really is a problem here to be fixed, but doing it in a way that 
attempts to get that message across in a humorous way to distract from 
the necessarily negative message.


 Best Regards,
Andy


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

[Talk-at] Wiener Kurzparkzonen

[Stefan Nagy]

Hallo,

ich habe gerade einen Fehlerbericht (note) gelesen, bei dem es um eine 
Parkmöglichkeit in Wien geht (siehe 
https://www.openstreetmap.org/note/1264962). Wenn ich das richtig 
interpretiere, dann geht es hier um das Vorhandensein eines 
Parkstreifens (also der Parkmöglichkeiten auf der Straße) und darum, 
dass das Parken hier etwas kostet – weil wir uns da in einer Wiener 
Kurzparkzone befinden.


Hier geht es mir jetzt nicht um den konkreten Fehlerbericht, sondern um 
eine allgemeine Frage: Kann man als Ziel definieren, dass wir mit 
parking:lane in Wien die Parkmöglichkeiten auf den Straßen eintragen und 
dabei die parking:condition-Attribute setzen, je nachdem, ob sich eine 
Straße in einer Kurzparkzone befindet? Spricht da irgendwas dagegen bzw. 
fallen euch bessere Möglichkeiten ein, die Kurzparkzonen zu mappen?


Beste Grüße,
Stefan.



--
E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/

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

Re: [Talk-it] disused:

[demon.box]

...ripresomi dal momentaneo "sconforto" per essere alla fine giunti
esattamente al punto dal quale eravamo partiti, mi sono comunque fatto un
po' quest'idea:

Il mio concetto base è far "sparire" dal rendering soltanto le funzioni e
non gli oggetti quindi mi ci ritrovo benissimo ad applicare il prefisso
disused: sugli amenity oppure sui landuse ma non sono affatto d'accordo
sulla sua applicazione ad esempio sui building, sui man_made, ecc.
Infatti nel caso di quest'ultimi io sto mappando l'oggetto aggiungendo
l'info che è in disuso ma non me lo devi far sparire magari me lo
renderizzerai con simbolo diverso ma NON deve sparire perchè di fatto c'è.

Anche perchè se invece il concetto base è metto disused: così la maggior
parte dei rendering non lo considereranno allora perchè non anteporre il
prefisso pippo:  ??? tanto il risultato è identico.

Quindi forse forse alla fine mi sà che seguirò davvero quello ha detto
@Dieterdreist:

utilizzerò sicuramente disused: sugli utilizzi di un oggetto o di un suolo
utilizzero invece disused=yes sugli oggetti semplicemente non più utilizzati

visto che, secondo me, il tag disused=yes non sparirà mai dal DB e quindi
saranno i programmi di elaborazione a doversi adeguare e non viceversa...

--enrico





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

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Bryan Housel]

Yes, I agree the feature could be improved.

Helpful:
- "I think it should be more clear that clicking the button will add a 
changeset comment”
- “I think localization could be improved and I’d love to help with this”
- “I would like the opportunity to customize the message or see it before it is 
posted”

Unhelpful:
- “This feature is spam equivalent to “Bitcoin Millions" ”
- “I am posting this to the talk list instead of directly working with the 
developer to improve it”
- “I have not even bothered to figure out which GitHub repo to open an issue in"
- “To European eyes the comments look like they were written by a six-year-old”


Be nice everyone!



> On Jan 12, 2018, at 9:25 AM, Mike N  wrote:
> 
> On 1/12/2018 9:13 AM, Bryan Housel wrote:
>> I love this feature, and I hope Wille keeps it in.
>> The message is very well written, and it’s not spam if the user asks for 
>> their changeset to be reviewed and then somebody actually does it.
> 
>  I haven't used this yet because I wanted to add my own detail to the 
> message.   A quick sampling of these shows that most are in response to 
> review_requested.   I did run across 2 that did not have review requested 
> however - the message is occasionally being used instead of a dedicated 
> thumbs up/down flag on changesets.
> 
> 
> ___
> 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] Automatically generated changeset discussion comments by OSMCha

[Andy Townsend]

On 12/01/2018 14:07, Michael Reichert wrote:

Hi,

OSMCha started posting comments to changesets a few days ago when a user
marks a changeset as good or bad.
https://www.openstreetmap.org/user/wille/diary/43101
I would like to ask the author(s) of OSMCha to disable this feature.


The example given at 
https://www.openstreetmap.org/user/wille/diary/43101 is certainly 
"insufficiently localised" to European eyes (alternatively, "written by 
a six-year-old") - every sentence ends with an exclamation mark*.


More seriously, any automatic use of OSM messages is problematical 
because it devalues the messages that we want people to actually read - 
the ones that are composed by and sent be a human, and have actual 
useful information in them (and I'm glad to see that Mike N said "I 
haven't used this yet because I wanted to add my own detail to the 
message" - that's exactly what should be happening).


Best Regards,
Andy

* apparently, according to 
http://www.bbc.com/culture/story/20170301-what-overusing-exclamation-marks-says-about-you 
, this is a matter of life and death :)



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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Mateusz Konieczny]

On Fri, 12 Jan 2018 15:07:11 +0100
Michael Reichert  wrote:

>  If third-party tools start to post comments to lots
> of changesets automatically

In that case that would be clearly wrong.

But if I understand 

> From now on, when we review a changeset in OSMCha, a comment will be
> posted in the OSM changeset page.

correctly then it is not automatic. It is posted from other tool/site
but allowing this is a purpose of API.

Is there any evidence that these
comments are spammy or used in de-facto automatic fashion? Os its it
really automatic and I misunderstand situation.

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Maarten Deen]

On 2018-01-12 15:07, Michael Reichert wrote:

Hi,

OSMCha started posting comments to changesets a few days ago when a 
user

marks a changeset as good or bad.
https://www.openstreetmap.org/user/wille/diary/43101
I would like to ask the author(s) of OSMCha to disable this feature.

We expect to read all mappers incoming message (personal messages and
changeset comments). If third-party tools start to post comments to 
lots
of changesets automatically, this is some kind of spamming. If OSM 
sends

to much emails to a user, the user will probably ignore them or treat
them as spam.

I think that OSMCha should not post a comment automatically except if
the user has explicitly asked for feedback or there are quality issues
regarding the edit (mistakes, vandalism, guideline violations or
anything else which makes it necessary to talk to the user).

I post this email to this mailing list instead of filing a bug report a
Github [1] because I want to bring this problem to the wider audience
and initiate a general discussion on the acceptable usage of the
changeset comments API.

What are your thoughts and opinions on this issue?


I agree. I would see a comment like that as very condescending.
Mind you: I have not used OSMcha and when I tried to use it 
(osmcha.mapbox.com ?) I can't seem to log in. I get a few error messages 
and the sign in box does nothing.

So I can't really check what kinds of edits would be affected by this.

Maarten

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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Mike N]

On 1/12/2018 9:13 AM, Bryan Housel wrote:

I love this feature, and I hope Wille keeps it in.
The message is very well written, and it’s not spam if the user asks for their 
changeset to be reviewed and then somebody actually does it.


  I haven't used this yet because I wanted to add my own detail to the 
message.   A quick sampling of these shows that most are in response to 
review_requested.   I did run across 2 that did not have review 
requested however - the message is occasionally being used instead of a 
dedicated thumbs up/down flag on changesets.



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

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

Am 2018-01-12 um 15:13 schrieb Bryan Housel:
> I love this feature, and I hope Wille keeps it in.
> The message is very well written, and it’s not spam if the user asks for 
> their changeset to be reviewed and then somebody actually does it.

It should be optional to post a changeset comment. If someone marks all
changesets in his home area as good, all changesets get a comment. If I
get a comment on all my changesets, I will write a filter on my personal
mail server to drop all these unsolicited emails (all comments with the
OSMCha default text). I can write filters on my own but I am sure that
many of our users are not able to do (or don't want to do and might
reduce their OSM activity).

Ideally, this comment should be localized. If a user uses the German
locale of his editor, he should the receive the comment in German if the
reviewer also uses a German locale (it is then very likely that they
would use German for their normal conversation). Receiving lots of
similar foreign-language comments is not far away from receiving ten
emails whose subject is "Bitcoin Millions".

That's why I consider it as some kind of spam (half of all recent
comments are just automatically generated):
http://resultmaps.neis-one.org/osm-discussions?c=Germany#6/51.727/9.338

All in all, the usage of the changeset discussions by OSMCha just points
out that a feature is missing on osm.org. This cannot be fully replaced
by a third-party application.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-cz] Dlouhé zimní večery.

[majka]

Řekla bych, že spíš možná obecně návod, jak dostat do mapy body, pokud mám
adresy.

Z mého pohledu pro uživatele tedy jak jednorázově, avšak dávkově
geokódovat, jak si připravit data, a jak to v JOSM projít jednotlivě a
zkontrolovat.

Pomíjím, že ne všechny zdroje je možné přebrat, ale část bodů dříve jsem
měla i stylem tužka papír (tedy zapsaná adresa + poznámky).

Tohle je třeba vhodné nejen na ty schránky, ale i na kontejnery na tříděný
odpad, pokud jsou někde zveřejněné jako opendata a podobné záležitosti. Ne
na všechno je nutný POI-importer, zvlášť v místním měřítku.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk] Fwd: Automatically generated changeset discussion comments by OSMCha

[Erwin Olario]

reposting an earlier reply, which i mistakenly sent directly just to Michael
-- Forwarded message -
From: Erwin Olario 
Date: Fri, Jan 12, 2018 at 10:15 PM
Subject: Re: [OSM-talk] Automatically generated changeset discussion
comments by OSMCha
To: Michael Reichert 


I believe it's a good idea. At present, any OSM user (and all OsmCha users,
are OSM users) can leave any comment to a changeset, whether or not the
mapper asked for any.

Earlier, I filed a ticket to enhance OsmCha behavior. Instead of posting a
default message, the reviewer should leave details outlining how the
changeset could be improved (or why they think it's bad.)

[0]: https://github.com/mapbox/osmcha-frontend/issues/248

On Fri, Jan 12, 2018 at 10:10 PM Michael Reichert 
wrote:

> Hi,
>
> OSMCha started posting comments to changesets a few days ago when a user
> marks a changeset as good or bad.
> https://www.openstreetmap.org/user/wille/diary/43101
> I would like to ask the author(s) of OSMCha to disable this feature.
>
> We expect to read all mappers incoming message (personal messages and
> changeset comments). If third-party tools start to post comments to lots
> of changesets automatically, this is some kind of spamming. If OSM sends
> to much emails to a user, the user will probably ignore them or treat
> them as spam.
>
> I think that OSMCha should not post a comment automatically except if
> the user has explicitly asked for feedback or there are quality issues
> regarding the edit (mistakes, vandalism, guideline violations or
> anything else which makes it necessary to talk to the user).
>
> I post this email to this mailing list instead of filing a bug report a
> Github [1] because I want to bring this problem to the wider audience
> and initiate a general discussion on the acceptable usage of the
> changeset comments API.
>
> What are your thoughts and opinions on this issue?
>
> Best regards
>
> Michael
>
>
> [1] Btw, which Github repository would be the correct one the file the
> bug report at?
> https://duckduckgo.com/?q=osmcha+github=ffsb=web
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin


-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Bryan Housel]

I love this feature, and I hope Wille keeps it in.
The message is very well written, and it’s not spam if the user asks for their 
changeset to be reviewed and then somebody actually does it.

Thanks Bryan


> On Jan 12, 2018, at 9:07 AM, Michael Reichert  wrote:
> 
> Hi,
> 
> OSMCha started posting comments to changesets a few days ago when a user
> marks a changeset as good or bad.
> https://www.openstreetmap.org/user/wille/diary/43101
> I would like to ask the author(s) of OSMCha to disable this feature.
> 
> We expect to read all mappers incoming message (personal messages and
> changeset comments). If third-party tools start to post comments to lots
> of changesets automatically, this is some kind of spamming. If OSM sends
> to much emails to a user, the user will probably ignore them or treat
> them as spam.
> 
> I think that OSMCha should not post a comment automatically except if
> the user has explicitly asked for feedback or there are quality issues
> regarding the edit (mistakes, vandalism, guideline violations or
> anything else which makes it necessary to talk to the user).
> 
> I post this email to this mailing list instead of filing a bug report a
> Github [1] because I want to bring this problem to the wider audience
> and initiate a general discussion on the acceptable usage of the
> changeset comments API.
> 
> What are your thoughts and opinions on this issue?
> 
> Best regards
> 
> Michael
> 
> 
> [1] Btw, which Github repository would be the correct one the file the
> bug report at?
> https://duckduckgo.com/?q=osmcha+github=ffsb=web
> 
> 
> -- 
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

[OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

OSMCha started posting comments to changesets a few days ago when a user
marks a changeset as good or bad.
https://www.openstreetmap.org/user/wille/diary/43101
I would like to ask the author(s) of OSMCha to disable this feature.

We expect to read all mappers incoming message (personal messages and
changeset comments). If third-party tools start to post comments to lots
of changesets automatically, this is some kind of spamming. If OSM sends
to much emails to a user, the user will probably ignore them or treat
them as spam.

I think that OSMCha should not post a comment automatically except if
the user has explicitly asked for feedback or there are quality issues
regarding the edit (mistakes, vandalism, guideline violations or
anything else which makes it necessary to talk to the user).

I post this email to this mailing list instead of filing a bug report a
Github [1] because I want to bring this problem to the wider audience
and initiate a general discussion on the acceptable usage of the
changeset comments API.

What are your thoughts and opinions on this issue?

Best regards

Michael


[1] Btw, which Github repository would be the correct one the file the
bug report at?
https://duckduckgo.com/?q=osmcha+github=ffsb=web


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [OSM-talk] Advertising on OSM

[Mateusz Konieczny]

On Fri, 12 Jan 2018 06:55:56 +0400 (GMT+04:00)
"Jack Armstrong dan...@sprynet.com"  wrote:

> I can't seem to find anything on the OSM Wiki.

Have you checked https://wiki.openstreetmap.org/wiki/Key:description ?

It has "Never use description=* to add advertising messages."

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

Re: [OSM-talk] Tool for tag tracking

[Pierre Béland]

Hi Roland. Great additions again.
I cannot access https://dev.overpass-api.de/api_new_feat/ to test.

Hi have the message Forbidden, You don't have permission to access 
/api_new_feat/on this server.

 
Pierre 
 

Le vendredi 12 janvier 2018 00:33:33 HNE, Roland Olbricht 
 a écrit :  
 
 Hi,

for the sake of completeness, I would like to give a preview what is in 
the development for Overpass API:

Similar to this one

> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass

you could nowadays search with https://overpass-turbo.eu/s/uF0
for all highways that have changed since the beginning of the year in 
and around Antwerp:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
out geom;

I suggest the "out geom" mode over recursing to the nodes. Overpass 
Turbo can handle both, but the "out geom" means that there is exactly 
one item per object in question. No unchanged nodes get involved.

The above result is bloated by objects like
https://www.openstreetmap.org/way/469659128/history
It has no change to its highway value but just lost the unrelated tag 
"horse=no".

Here comes a feature in the staging area for the next version into play. 
We do not ask for all changes but just for changes that affect the tag 
"highway": https://overpass-turbo.eu/s/uF2

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:t[highway]);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

The line "compare(delta:t[highway]);" reads as: keep only objects that 
have changed in the value "t[highway]". The last line is a directive to 
execute the query on the development server.

We could even drill down further and retrieve only objects that have 
been created or deleted: https://overpass-turbo.eu/s/uF4

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

This is admittedly hacky and the final implementation might have a more 
straightforward term. The condition for "compare" always evaluates to 
the empty string for non-existing objects. And for existing objects to 
"0" as we just have specified, hence it can tell apart existing from 
non-existing objects.

Can we separate the deleted from the created objects? Yes,
https://overpass-turbo.eu/s/uF7 delivers only created objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  way._(newer:"2018-01-01T00:00:01Z");
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

And https://overpass-turbo.eu/s/uFa delivers only deleted objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

Please note that these are not yet in a published release because there 
may come up a reason to change the syntax. If that happens, I will write 
a mail here again. For example, it might be more concise to do these 
tasks with a three argument "changed" condition. But I have not 
evaluated yet whether this leads to a logically sound syntax.

Best regards,
Roland


___
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: [Talk-cz] Dlouhé zimní večery.

[Miroslav Suchý]

Dne 11.1.2018 v 22:53 Jan Dudík napsal(a):
> Určitě by stálo za to (Majka) popsat mapování poštovních schránek.

Spise vice rozepsat:
  https://openstreetmap.cz/poi-importer

Mirek

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

Re: [OSM-talk] Tool for tag tracking

[Tobias Zwick]

Wow, Roland, this is awesome!

So, this seems to make any deliberations of introducing a
survey_date:something tag or similar obsolete, because in the future,
one will be able to search with overpass through the history on a
per-tag basis.

This will make it possible for QA and hm... data-actuality-maintenance
tools (made up this term, this category of tools doesn't exist yet I
guess) to find data that haven't been changed for a long time and should
be re-checked some time.
I am thinking of finding automatically certain data points (tags) that
haven't changed in the database for X months and should be re-surveyed.
Will that be possible also (checking for "last change on tag older
than...")?

This feature makes it possible to greatly improve the maintainability of
data in openstreetmap.
For example the smoothness of streets and cycleways in particular is
something that should be revisited every few years, same as the street
surface especially in developing countries. Also, the presence of
cycleways on streets might be something that should be re-checked every
decade or so at least. Etc etc

Great work!

Cheers
Tobias

On 12/01/2018 06:31, Roland Olbricht wrote:
> Hi,
> 
> for the sake of completeness, I would like to give a preview what is in
> the development for Overpass API:
> 
> Similar to this one
> 
>> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass
>>
> 
> you could nowadays search with https://overpass-turbo.eu/s/uF0
> for all highways that have changed since the beginning of the year in
> and around Antwerp:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> out geom;
> 
> I suggest the "out geom" mode over recursing to the nodes. Overpass
> Turbo can handle both, but the "out geom" means that there is exactly
> one item per object in question. No unchanged nodes get involved.
> 
> The above result is bloated by objects like
> https://www.openstreetmap.org/way/469659128/history
> It has no change to its highway value but just lost the unrelated tag
> "horse=no".
> 
> Here comes a feature in the staging area for the next version into play.
> We do not ask for all changes but just for changes that affect the tag
> "highway": https://overpass-turbo.eu/s/uF2
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:t[highway]);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> The line "compare(delta:t[highway]);" reads as: keep only objects that
> have changed in the value "t[highway]". The last line is a directive to
> execute the query on the development server.
> 
> We could even drill down further and retrieve only objects that have
> been created or deleted: https://overpass-turbo.eu/s/uF4
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> This is admittedly hacky and the final implementation might have a more
> straightforward term. The condition for "compare" always evaluates to
> the empty string for non-existing objects. And for existing objects to
> "0" as we just have specified, hence it can tell apart existing from
> non-existing objects.
> 
> Can we separate the deleted from the created objects? Yes,
> https://overpass-turbo.eu/s/uF7 delivers only created objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   way._(newer:"2018-01-01T00:00:01Z");
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> And https://overpass-turbo.eu/s/uFa delivers only deleted objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> Please note that these are not yet in a published release because there
> may come up a reason to change the syntax. If that happens, I will write
> a mail here again. For example, it might be more concise to do these
> tasks with a three argument "changed" condition. But I have not
> evaluated yet whether this leads to a logically sound syntax.
> 
> Best regards,
> Roland
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

[Talk-it] Bacheche pubbliche

[Cascafico Giovanni]

Tempo fa si era parlato di quella per i necrologi e, durante la
discussione, era uscita anche una possibile definizione generica con la
coppia di tag:

tourism=information
information=board

Credo che questo tipo di PDI non sia così marginale., per cui vi chiedo se
c'è un'alternativa, visto che le bacheche per annunci istituzionali (ma
anche dei film al cinema) non sono poi così a loro agio nel gruppo
"tourism" [1].



[1] https://it.wikipedia.org/wiki/Turismo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] maxspeed:type vs source:maxspeed

[Rodrigo Vivar]

On sait pas todo, faut attendre, mais presque sûr aprés décrét y aura dans osm :

1- des highway + maxspeed=90 datant d'avant décret + parfois  FR:rural

2- des highway + maxspeed=90 datant d'apres décret ??


3- des highway + maxspeed=80 datant d'apres décret ??

 

pour distinguer 1 et 2 serait pas bien par ex. "fixme=90 avant décrets" à mettre suivant décret national, regional, dpartmnt ... ?

 

Rod

 


From: osm.sanspourr...@spamgourmet.com

Quel maxspeed:type pour le type 80 "campagne" et le 90 voies séparées ?

Jean-Yvon

 



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

Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data

[Christoph Hormann]

On Friday 12 January 2018, Rory McCann wrote:
> As near as I can see, the only data they are distributing (publicly)
> is the 2 GeoTIFF files in the "map.ox.ac.uk" page. The question is:
> Is a GeoTIFF file created like this from OSM data which has been
> mixed with other data, a Produced Work, or a Derived Database?

No, that is not significant - see 4.4c of the ODbL:

Derivative Databases and Produced Works. A Derivative Database is
Publicly Used and so must comply with Section 4.4. if a Produced Work
created from the Derivative Database is Publicly Used.

So the question is only if there is a derivative database involved in 
the production of the GeoTIFF, not if the GeoTIFF itself is a 
derivative database.  My view would be that the aggregation of data 
from the OSM database and the Google roads data when creating the 
raster map constitutes a derivative database even if the two data sets 
are not physically merged into a common table because this happens on 
the fly.  See:

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline

"Technically a reference between non-OSM and OSM data can be by a 
database key or any other method of identifying a specific OSM or 
non-OSM element that may be used with a database join."

So if for the purpose of creating the raster map you query all OSM roads 
within each pixel, determine which Google roads are within a pixel size 
distance of the pixel center (or something like that) and calculate the 
minimum friction value of those this is technically "a reference 
between non-OSM and OSM data" IMO.

> *But* (possibly stupid question time) I'm reading the ODbL and it
> (Sec 4.6) only requires that you make the derived database available
> *or* the original scripts, and original contents. By releasing the
> GeoTiff file(s) they've fulfilled Sec 4.6(a), no?

No, the GeoTIFF is quite clearly a produced work as per the ODbL:

"a work (such as an image, audiovisual material, text,
or sounds) resulting from using the whole or a Substantial part of the
Contents (via a search or other query) from this Database, a Derivative
Database, or this Database as part of a Collective Database."

And the produced work guideline:

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline

"The published result of your project is either a Produced Worked or a 
Derivative Database within the meaning of the ODbL. If the published 
result of your project is intended for the extraction of the original 
data, then it is a database and not a Produced Work."


One point you could argue is that you could produce the friction map by 
separately rasterizing the OSM and Google roads data and then merge 
what is already a produced work with a minimum operator on the two 
raster files.  Since the raster is already a produced work you could 
argue that the ODbL does not apply then.  But on the other hand you 
could argue (as you already did in your mail) that once you use a 
produced work in a database-like fashion it becomes a derivative 
database again - the same way as if you trace features from a rendered 
OSM map.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data

[Rory McCann]

As near as I can see, the only data they are distributing (publicly) is
the 2 GeoTIFF files in the "map.ox.ac.uk" page. The question is: Is a
GeoTIFF file created like this from OSM data which has been mixed with
other data, a Produced Work, or a Derived Database?

In support of "Produced Work", GeoTIFF is (on paper) *literally* an
image file format. Images (AFAIK) based on OSM data have always been
viewed as produced works, so this shouldn't be different.

In support of "Derived Database", these GeoTIFFs do feel like a
database. The files don't have any artistic styling, they are basically
a 2D arrangement of numbers, you can import it into a geo database (like
PostGIS), you can query the file for "what's the value at this point?",
it's only useful if you decide to style it as you decide. The project
itself has used one of these GeoTIFFs as input data for another process,
etc.

IMO these GeoTIFF files are (overwhelmingly) more like a database than
an image.

*But* (possibly stupid question time) I'm reading the ODbL and it (Sec
4.6) only requires that you make the derived database available *or* the
original scripts, and original contents. By releasing the GeoTiff
file(s) they've fulfilled Sec 4.6(a), no? Isn't that enough for the 
share-alike aspect? And they aren't required to release all the other

original (Google) data?

Obviously if it's a Derived Database, they need to release it under the
ODbL licence (or similar). The page says CC-BY and that isn't right at all.

On 11/01/18 16:30, Christoph Hormann wrote:


Today i stumbled across this:

https://map.ox.ac.uk/research-project/accessibility_to_cities/
http://dx.doi.org/doi:10.1038/nature25181
https://explorer.earthengine.google.com/#detail/Oxford%2FMAP%2Faccessibility_to_cities_2015_v1_0

Apart from partly insufficient attribution (which i already contacted
the author about) this is an interesting case example of combining OSM
with proprietary data sets i would like to hear some opinions about.

What is done here is combining road information (and some other data)
from OSM and proprietary data sources (Google) into a raster map (made
available as 'friction surface' under the first link above) and doing
further processing, analysis and map rendering based on that and
publishing the result.

My interpretation of the ODbL here is that this is a share-alike case
that would require the combined data sources to be made available.  But
you could probably also look at it differently.  I would like to hear
opinions on this.  In particular if you think that is legally possible
without share alike how this interpretation looks like.





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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

[Alarig Le Lay]

Hello,

Vu d’ici, l’IPv6 de Londres a été réparé, d’après ma probe atlas depuis
le 2018-01-11 05:51:36 UTC, et la panne a durée 6d 23h 6m.

https://atlas.ripe.net/probes/11556/#!tab-network

Voici des mtr dans les deux sens qui ne marchaient pas durant cette
panne :
https://paste.swordarmor.fr/u638
https://paste.swordarmor.fr/7zz1

-- 
alarig


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

Re: [OSM-talk-fr] changement possible de maxspeed en france au 1er juillet

[Christian Quest]

Il faudra voir le décret lorsqu'il sera publié... là on est encore au stade
"annonce".

Le 11 janvier 2018 à 23:38, marc marc  a écrit :

> Le 11. 01. 18 à 22:53, osm.sanspourr...@spamgourmet.com a écrit :
> > Quel maxspeed:type pour le type 80 "campagne" et le 90 voies séparées ?
> c'est quoi exactement (mais en ultra résumé) la règle à venir ?
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-be] Open Belgium

[Nicolas Pettiaux]

As said, I'll be there. I have submitted a talk about openseamap : «
mapping the depth of the Belgian seaside »

For this project, I am writing a proposal to get some financial support,
eg/ from the communes/gemeenten on the seaside and from the Flemish
government. Some help will be welcome for this project as my knowledge
of Flemisch is not sufficient to write in proper Flemisch

I will also present the educode.be international conference to be held
at Bozar, ESI and the Royal Académie on August 27, 28 and 29 that will
be about teaching and coding and the use of free softwares and free
datas in the classrooms. Any helps, suggestions, ideas, proposals are
welcome (See http://educode.be for more info now)

Regards,

Nicolas

Le 12/01/18 à 10:36, Julien Minet a écrit :
> Hi Joost, Hi list,
> 
> I'll be there! And I plan to submit something about land-use in OSM. It
> could be a workshop. If someone wants to join in the authors/speakers,
> let me know! It would be better to have different points of view. 
> 
> There is also the subject of the cooperation between Sentiers Grandes
> Randonnées & OSM that could be interesting, but maybe for another
> workshop...
> 
> Julien
> 
> 
> 
> On Wed, Jan 10, 2018 at 9:21 AM, joost schouppe
> > wrote:
> 
> Hi,
> 
> The next Open Belgium conference is coming up, bringing together the
> entire "open community" of Belgium. It's not just about official
> open data providers and users, but also open knowledge, open source,
> and of course us, OpenStreetMap in Belgium.
> 
> http://2018.openbelgium.be/
> 
> Since OpenStreetMap Belgium is one of the working groups of Open
> Knowledge Belgium, we can do stuff during the conference. What we
> do, is up to you! If you've done anything with regards to OSM that
> you would like to share, now is the time. For now, the deadline for
> proposals is this Sunday. Early bird tickets also end soon (though
> send me a PM if ticket price is an issue). So time for action!
> 
> Things we were thinking about ourselves:
> - talk about OSM Belgium, organisational as well as our projects
> - maybe some of escada's projects, like what the Fietsersbond has
> been up to
> - the GBB import
> - Trage Wegen (they always do cool stuff with OSM and open knowledge
> creation)
> - last year's Open Summer of Code students
> - have that long overdue landuse debate 
> - an introduction to humanitarian mapping
> - [ your proposal here ]
> 
> Don't be shy, don't hesitate to contact me or commun...@osm.be
>  with questions. Hope to see you there!
> 
> 
> -- 
> Joost Schouppe
> 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
> 

-- 
*Nicolas Pettiaux* PhD, AESS, EMM - Tel +32 496 24 55 01
Maître-assistant - École supérieure d'informatique - ESI
http://esi-bru.be Haute école Bruxelles-Brabant - HE2B - http://he2b.be
Laboratories of Image, Signal processing & Acoustics - ULB
http://lisa.ulb.ac.be/ *http://EduCode.be - Conférence internationale
sur l'enseignement et le codage, Bozar, Bruxelles, 27-29 août 2018*
*http://EduCode.be - An international conference on teaching and coding,
Bozar, Brussels, 27-29 August 2018*
<>___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Open Belgium

[Julien Minet]

Hi Joost, Hi list,

I'll be there! And I plan to submit something about land-use in OSM. It
could be a workshop. If someone wants to join in the authors/speakers, let
me know! It would be better to have different points of view.

There is also the subject of the cooperation between Sentiers Grandes
Randonnées & OSM that could be interesting, but maybe for another
workshop...

Julien



On Wed, Jan 10, 2018 at 9:21 AM, joost schouppe 
wrote:

> Hi,
>
> The next Open Belgium conference is coming up, bringing together the
> entire "open community" of Belgium. It's not just about official open data
> providers and users, but also open knowledge, open source, and of course
> us, OpenStreetMap in Belgium.
>
> http://2018.openbelgium.be/
>
> Since OpenStreetMap Belgium is one of the working groups of Open Knowledge
> Belgium, we can do stuff during the conference. What we do, is up to you!
> If you've done anything with regards to OSM that you would like to share,
> now is the time. For now, the deadline for proposals is this Sunday. Early
> bird tickets also end soon (though send me a PM if ticket price is an
> issue). So time for action!
>
> Things we were thinking about ourselves:
> - talk about OSM Belgium, organisational as well as our projects
> - maybe some of escada's projects, like what the Fietsersbond has been up
> to
> - the GBB import
> - Trage Wegen (they always do cool stuff with OSM and open knowledge
> creation)
> - last year's Open Summer of Code students
> - have that long overdue landuse debate
> - an introduction to humanitarian mapping
> - [ your proposal here ]
>
> Don't be shy, don't hesitate to contact me or commun...@osm.be with
> questions. Hope to see you there!
>
>
> --
> Joost Schouppe
> 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