Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Une partie (à priori) des données d'AED Map sont publiées sur data.gouv 
: https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/


Cela ne concerne que ceux déclarés par les collectivités, donc pas la 
partie contribution bénévole. Une fusion de ces jeux de données en août 
2019 par Christian laissait ressortir 900 DAE de cette base. Je ne sais 
pas dans quelle mesure ils ont été contactés pour diffuser les données 
créées par les bénévoles.


Cordialement,

Adrien P.

Le 04/08/2020 à 23:51, Francois Gouget a écrit :


Quelqu'un sait-il sur quelle base de donnée s'appuie l'application
Staying Alive ? Et surtout quelle est la license de cette base de
donnée de défibillateurs ?

Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur
le site de AEDMap rien de bien précis : https://aedmap.org/

J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le
travail de bénévoles. Mais leur coeur de métier ne semble pas être cette
base de donnée mais plutôt la maintenance de défibrillateurs.


Bon indépendamment de ça j'ai décidé de prendre un peu d'avance et j'ai
ajouté un défibrillateur à Montparnasse. Un modèle solaire que je
n'avais jamais vu avant et qui serait opéré par la Ville de Paris (3ème
photo) :
https://www.paris.fr/pages/mille-defibrillateurs-prevus-a-paris-d-ici-cinq-ans-4567

Et la carte dépassée et illisible des mille^H^H^H ~100 défibrillateurs
de cette initiative :
http://labs.paris.fr/commun/pdf/carte_33_sites.pdf

Tiens, ça fait penser au xkcd d'aujourd'hui https://xkcd.com/2341/


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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

[Gad Jo]

Je me suis mal exprimé

L'analyse Osmose serait pour les point d'entrée de ville. Pas pour les way qui 
ne respecte pas les admin_level existant

Si ça peut permettre de placer les panneaux d'entrée/sortie de commune ce 
serait pas mal (et autres infos placée au même endroit)

Le August 4, 2020 7:13:56 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
> > Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette
>anomalie vers Osmose pour ajouter un nouveau contrôle ?
>
>Peut-être parce que la seule possibilité c'est de supprimer cette
>infox.
>
>Sur les 4639 points ajoutés par notre ami, approximativement 703 sont
>sur des highway (703 routes passent par ces points).
>
>Concernant 4 000 points environ : on a l'information que le
>contributeur
>a estimé que la limite urbaine c'était par là (au vue d'une imagerie
>_aérienne_ comme si les limites correspondaient forcément !).
>
>Absolument pas parce qu'il y a un panneau là.
>
>Donc tu fais quoi ? Tu regardes une imagerie de rue pour voir s'il y a
>un panneau dans le coin ?
>
>Non, supprimer ces 4 000 points c'est hélas la bonne solution.
>
>À ne pas confondre avec le cas de Florian (il a vu le panneau et a mis
>la limite non au niveau de la route mais au niveau du panneau, il peut
>mettre à jour sans problème).
>
>Jean-Yvon
>
>
>Le 04/08/2020 à 07:28, Gad Jo - perche...@toutenkamion.net a écrit :
>>
>>
>> Je suis sûr que d'autre contributeur en ont créé de la même façon et
>> qu'il pourraient bénéficier de ce type de correction.
>> Au passage ça évite les suppression accidentelle de nœud où d'autres
>> tag seraient ajoutés (honnêtement ça m'étonnerait mais autant
>prévoir).
>>
>> Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT
>>  a écrit :
>>
>> Je viens d'envoyer un message par la messagerie interne
>d'osm.org.
>> J'attends donc encore un peu avant de passer au
>> traffic_sign=city_limit.
>>
>> Romain
>>
>>> De : Christian Quest 
>>> À : talk-fr@openstreetmap.org
>>> Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un
>>> aire urbaine imaginaire ?
>>> Date : 03/08/2020 09:00:10 Europe/Paris
>>>
>>> Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
>>> > Les hésitations ont trop duré, c'est souvent le problème dans
>>> OSM, on
>>> > n'ose pas toujours pour ne pas froisser des susceptibilités.
>Je
>>> n'ai
>>> > rien contre le tag boundary=urban, c'est juste que dans le cas
>>> > présent, son emploi s'est fait sans tenir compte des données
>déjà
>>> > présentes...
>>> >
>>> > Romain
>>> >
>>> Pour ça que la première chose à faire est de prendre contact
>avec le
>>> contributeur avant de faire la modification massive, surtout
>>> quand c'est
>>> un régulier comme ici.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> --
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Christoph Hormann]

On Tuesday 04 August 2020, Rory McCann wrote:
> The Board hasn't decided on how the panel will be
> formed/elected/appointed/choosen.

Quoting from the proposal:

> In appointing members of the Panel, the Board shall strive for Panel 
composition (membership) that reflects [...]

Seems there are some eddies in the fabric of spacetime...

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

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

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Mikel Maron]

More seriously the line “all interests of the OSM community” was one we talked 
a lot about on the board when writing this message, and had several versions, 
and indeed we touched on how to best designate what was needed in composition 
of the panel. I think it’s not possible to put together a specific formula, but 
think we should expand this section to touch on the kinds of things we would 
hope to see in the composition of the board. That certainly would be experience 
and expertise with OSM community and software development and mapping. I don’t 
think anyone is impartial on anything but we’d want people who are recognized 
as open minded.
We haven’t talked at all about transparency of selection and deliberations. I’m 
not sure it’s wise to be completely open in the work of disputes, but certainly 
having deliberations well minutes and explained makes sense.

Mikel

On Tuesday, August 4, 2020, 5:42 PM, Mikel Maron  wrote:

It was a joke more aimed at Rory and a continuation of the similar discussion 
we’ve had on the board.
And yes I agree very much with the sentiment that we don’t want OSM to be 
dominated by companies. or any single point of view for that matter.
I’ve come to not like that quote because I don’t believe it’s often the case. 
And I think that there’s a lot of decisions which are favorable to all involved 
in osm, whether giant company or a single mapper. The dichotomy is not that 
pronounced if you look closely.

Mikel

On Tuesday, August 4, 2020, 5:31 PM, Joseph Eisenberg 
 wrote:

Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of 
corporate sell outs rubber stamping iD decisions and squashing the common 
mapper into conformity. Why else would we be doing this?"
This sarcastic comment is not a fair response to Christoph's concerns.
While we hope that no one involved currently in OpenStreetMap would 
purposefully turn the community over to corporations, it is certainly possible 
to imagine this to happen little by little, if the community is eroded slowly, 
lacking safeguards and clear goals.
If the people who become leaders of the OpenStreetMap community have all of 
their experience and ideals based in the corporate tech sector, it will be 
unsurprising if they are naturally inclined to make decisions which are 
favorable to the interests of Facebook, Apple or Amazon, whether or not they 
benefit the OpenStreetMap community. 
As a famous American reformer (Upton Sinclair) often said: "It is difficult to 
get a man to understand something, when his salary depends upon his not 
understanding it." 
– Joseph Eisenberg
On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron  wrote:

Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate 
sell outs rubber stamping iD decisions and squashing the common mapper into 
conformity. Why else would we be doing this?

On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann  
wrote: 





The Board hasn't decided on how the panel will be 
formed/elected/appointed/choosen. Just because the document doesn't 
address one issue, doesn't mean the opposite, horrible option will 
happen. Do you think I'm going to support some Old Boy's Network of 
corporate employees?

What would you suggest for appointing & transparency?

On 04.08.20 21:30, Christoph Hormann wrote:
> On Tuesday 04 August 2020, Dorothea Kazazi wrote:
>>
>> The OSMF board just published a proposal for a software
>> dispute resolution panel:
>> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
>> te-resolution-panel/
> 
> I guess i am asking too much if i envision the board creating a panel it
> does not control itself...
> 
> For context - the DWG, which is the traditional and broadly respected
> entity to resolve conflicts in mapping, is not controlled in
> composition by the board, it decides on accepting new members
> themselves.  See also:
> 
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> 
> Significant parts of the authority the DWG has among mappers derive from
> the fact that it is not composed of political appointees.
> 
> Interesting also that the composition of the panel is supposed to
> reflect "all interests of the OSM community" but competence of the
> panel members on the subject, experience with and knowledge of mapping
> and tagging in OSM or in other words:  The competence to assess
> evidence on the cases they deal with and to deliberate on the matters
> in a qualified and knowledgable way, is not a criterion.  Neither is
> impartiality on prominent special interests like those of corporate
> data users.
> 
> Transparency is limited to the ultimate decisions being made public
> (indeed important, would be interesting how this would function
> otherwise).  I guess that means both the nominations and selection of
> panel members as well as the deliberation and consulting of the panel
> on cases 

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Francois Gouget]

On Tue, 4 Aug 2020, PanierAvide wrote:
[...]
> Il y a quelques semaines, la Direction Générale de la Santé a publié sa 
> base GéoDAE (en cours de constitution), qui recense les défibrillateurs 
> du pays.
[...]
> En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. 
> Évidemment les deux bases ne se recoupent pas, certains DAE sont 
> présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. 

Quelqu'un sait-il sur quelle base de donnée s'appuie l'application 
Staying Alive ? Et surtout quelle est la license de cette base de 
donnée de défibillateurs ?

Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur 
le site de AEDMap rien de bien précis : https://aedmap.org/

J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le 
travail de bénévoles. Mais leur coeur de métier ne semble pas être cette 
base de donnée mais plutôt la maintenance de défibrillateurs.


Bon indépendamment de ça j'ai décidé de prendre un peu d'avance et j'ai 
ajouté un défibrillateur à Montparnasse. Un modèle solaire que je 
n'avais jamais vu avant et qui serait opéré par la Ville de Paris (3ème 
photo) :
https://www.paris.fr/pages/mille-defibrillateurs-prevus-a-paris-d-ici-cinq-ans-4567

Et la carte dépassée et illisible des mille^H^H^H ~100 défibrillateurs 
de cette initiative :
http://labs.paris.fr/commun/pdf/carte_33_sites.pdf

Tiens, ça fait penser au xkcd d'aujourd'hui https://xkcd.com/2341/

-- 
Francois Gouget   http://fgouget.free.fr/
   Cahn's Axiom: When all else fails, read the instructions.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Mikel Maron]

It was a joke more aimed at Rory and a continuation of the similar discussion 
we’ve had on the board.
And yes I agree very much with the sentiment that we don’t want OSM to be 
dominated by companies. or any single point of view for that matter.
I’ve come to not like that quote because I don’t believe it’s often the case. 
And I think that there’s a lot of decisions which are favorable to all involved 
in osm, whether giant company or a single mapper. The dichotomy is not that 
pronounced if you look closely.

Mikel

On Tuesday, August 4, 2020, 5:31 PM, Joseph Eisenberg 
 wrote:

Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of 
corporate sell outs rubber stamping iD decisions and squashing the common 
mapper into conformity. Why else would we be doing this?"
This sarcastic comment is not a fair response to Christoph's concerns.
While we hope that no one involved currently in OpenStreetMap would 
purposefully turn the community over to corporations, it is certainly possible 
to imagine this to happen little by little, if the community is eroded slowly, 
lacking safeguards and clear goals.
If the people who become leaders of the OpenStreetMap community have all of 
their experience and ideals based in the corporate tech sector, it will be 
unsurprising if they are naturally inclined to make decisions which are 
favorable to the interests of Facebook, Apple or Amazon, whether or not they 
benefit the OpenStreetMap community. 
As a famous American reformer (Upton Sinclair) often said: "It is difficult to 
get a man to understand something, when his salary depends upon his not 
understanding it." 
– Joseph Eisenberg
On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron  wrote:

Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate 
sell outs rubber stamping iD decisions and squashing the common mapper into 
conformity. Why else would we be doing this?

On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann  
wrote: 





The Board hasn't decided on how the panel will be 
formed/elected/appointed/choosen. Just because the document doesn't 
address one issue, doesn't mean the opposite, horrible option will 
happen. Do you think I'm going to support some Old Boy's Network of 
corporate employees?

What would you suggest for appointing & transparency?

On 04.08.20 21:30, Christoph Hormann wrote:
> On Tuesday 04 August 2020, Dorothea Kazazi wrote:
>>
>> The OSMF board just published a proposal for a software
>> dispute resolution panel:
>> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
>> te-resolution-panel/
> 
> I guess i am asking too much if i envision the board creating a panel it
> does not control itself...
> 
> For context - the DWG, which is the traditional and broadly respected
> entity to resolve conflicts in mapping, is not controlled in
> composition by the board, it decides on accepting new members
> themselves.  See also:
> 
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> 
> Significant parts of the authority the DWG has among mappers derive from
> the fact that it is not composed of political appointees.
> 
> Interesting also that the composition of the panel is supposed to
> reflect "all interests of the OSM community" but competence of the
> panel members on the subject, experience with and knowledge of mapping
> and tagging in OSM or in other words:  The competence to assess
> evidence on the cases they deal with and to deliberate on the matters
> in a qualified and knowledgable way, is not a criterion.  Neither is
> impartiality on prominent special interests like those of corporate
> data users.
> 
> Transparency is limited to the ultimate decisions being made public
> (indeed important, would be interesting how this would function
> otherwise).  I guess that means both the nominations and selection of
> panel members as well as the deliberation and consulting of the panel
> on cases is going to happen behind closed doors.
> 

___
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 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] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Joseph Eisenberg]

Re: "Rory, I don't know about you, but I'm certainly hoping for a bunch of
corporate sell outs rubber stamping iD decisions and squashing the common
mapper into conformity. Why else would we be doing this?"

This sarcastic comment is not a fair response to Christoph's concerns.

While we hope that no one involved currently in OpenStreetMap would
purposefully turn the community over to corporations, it is certainly
possible to imagine this to happen little by little, if the community is
eroded slowly, lacking safeguards and clear goals.

If the people who become leaders of the OpenStreetMap community have all of
their experience and ideals based in the corporate tech sector, it will be
unsurprising if they are naturally inclined to make decisions which are
favorable to the interests of Facebook, Apple or Amazon, whether or not
they benefit the OpenStreetMap community.

As a famous American reformer (Upton Sinclair) often said: "It is difficult
to get a man to understand something, when his salary depends upon his not
understanding it."

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 2:08 PM Mikel Maron  wrote:

> Rory, I don't know about you, but I'm certainly hoping for a bunch of
> corporate sell outs rubber stamping iD decisions and squashing the common
> mapper into conformity. Why else would we be doing this?
>
> On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann <
> r...@technomancy.org> wrote:
>
>
>
>
>
> The Board hasn't decided on how the panel will be
> formed/elected/appointed/choosen. Just because the document doesn't
> address one issue, doesn't mean the opposite, horrible option will
> happen. Do you think I'm going to support some Old Boy's Network of
> corporate employees?
>
> What would you suggest for appointing & transparency?
>
> On 04.08.20 21:30, Christoph Hormann wrote:
> > On Tuesday 04 August 2020, Dorothea Kazazi wrote:
> >>
> >> The OSMF board just published a proposal for a software
> >> dispute resolution panel:
> >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
> >> te-resolution-panel/
> >
> > I guess i am asking too much if i envision the board creating a panel it
> > does not control itself...
> >
> > For context - the DWG, which is the traditional and broadly respected
> > entity to resolve conflicts in mapping, is not controlled in
> > composition by the board, it decides on accepting new members
> > themselves.  See also:
> >
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> >
> > Significant parts of the authority the DWG has among mappers derive from
> > the fact that it is not composed of political appointees.
> >
> > Interesting also that the composition of the panel is supposed to
> > reflect "all interests of the OSM community" but competence of the
> > panel members on the subject, experience with and knowledge of mapping
> > and tagging in OSM or in other words:  The competence to assess
> > evidence on the cases they deal with and to deliberate on the matters
> > in a qualified and knowledgable way, is not a criterion.  Neither is
> > impartiality on prominent special interests like those of corporate
> > data users.
> >
> > Transparency is limited to the ultimate decisions being made public
> > (indeed important, would be interesting how this would function
> > otherwise).  I guess that means both the nominations and selection of
> > panel members as well as the deliberation and consulting of the panel
> > on cases is going to happen behind closed doors.
> >
>
> ___
> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-es] ayuda con diferentes tipos de aparcamiento

[emilio]

Hola

En estos días, sobre todo los fines de semana, me encuentro mapeando la ciudad 
de Alicante, y tengo algunas dudas acerca de emplear áreas, nodos o 
combinaciones de etiquetas en las zonas de aparcamiento reservadas.

En concreto, estas son mis dudas por partes:

APARCAMIENTO PARA MOTOCICLETAS


  *
Si se encuentran dentro de una zona de parking suelo dibujar un área etiquetada 
como “amenity=motorcycle_parking; como ejemplo este changeset: 
#88841697
  *
Si se encuentran formando parte de un carril de aparcamiento ¿se señaliza con 
un área o con un nodo? En este caso quiero señalizar una zona en Calle Músico 
José Torregrosa de unas 8 plazas, con la particularidad de que el aparcamiento 
general en esa calle es en paralelo, mientras que en la zona reservada para 
motos es en perpendicular. ¿habría que dividir la calle en ese punto para 
indicar que la forma de aparcamiento en esa calle cambia de paralelo a 
perpendicular?

APARCAMIENTOS DE MINUSVÁLIDOS


  *
https://www.openstreetmap.org/note/2214500 aquí pedía ayuda para señalizar 
correctamente 2 sitios de aparcamiento reservados para minusválidos dentro de 
un parking de una tienda, pero me ha quedado la duda de que si hay que 
mapearlos igual cuando se encuentran dentro de un carril de aparcamiento de una 
calle

PARADAS DE BUS URBANO Y RESERVADOS PARA BUS ESCOLAR EN ZONAS ESCOLARES


  *   #87405332 en este 
changeset, que hizo el usuario Jordi MF tras pedir yo revisión de conjuntos de 
cambios, se especifican las condiciones en las que un carril de aparcamiento 
junto a un instituto se reserva para el servicio de bus escolar del instituto , 
siendo libre el resto del día - 1 ¿hay alguna etiqueta para especificar que el 
reservado es para buses escolares? 2 - ¿se podría aplicar en las paradas de bus 
urbano cambiando el horario a este: de lunes a domingo de 6 a 23 horas, que es 
el intervalo de tiempo en que funciona diariamente el servicio de bus urbano de 
Alicante? Aquí sí que tengo claro que sólo lo usaría en paradas que estén 
debidamente señalizadas con pintura viaria

PARADAS DE TAXIS


  *
En este caso ¿es preferible usar un nodo o marcar un área? yo me inclino más 
por dibujar un área, sobre todo si la parada es extensa

Espero vuestra ayuda, y que las respuestas que aquí se den puedan ayudar a 
otros usuarios



Enviado desde Correo de Windows

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

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Yuri Astrakhan]

Mikel, I might be misunderstanding what you meant, but in my opinion
conformity is required for this type of project, and I do hope iD/JOSM/...
help us achieve that. To clarify:

* features with the same meaning (type) should be mapped the same way,
otherwise each consumer must understand all of them, and only large
corporations will be able to hire enough people to parse & handle it all.

* it should be relatively simple for the community to add new types, and
later to converge on how to map that new type, thus becoming a new
"standard".

* multiple editors should encourage users to map the same types of features
in the same way.

So yes, conformity is good because it allows us (consumers) to make sense
of the data without having an army of developers.

Hope I'm making sense here, and stating the obvious. Captain out. :)


On Tue, Aug 4, 2020 at 5:08 PM Mikel Maron  wrote:

> Rory, I don't know about you, but I'm certainly hoping for a bunch of
> corporate sell outs rubber stamping iD decisions and squashing the common
> mapper into conformity. Why else would we be doing this?
>
> On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann <
> r...@technomancy.org> wrote:
>
>
>
>
>
> The Board hasn't decided on how the panel will be
> formed/elected/appointed/choosen. Just because the document doesn't
> address one issue, doesn't mean the opposite, horrible option will
> happen. Do you think I'm going to support some Old Boy's Network of
> corporate employees?
>
> What would you suggest for appointing & transparency?
>
> On 04.08.20 21:30, Christoph Hormann wrote:
> > On Tuesday 04 August 2020, Dorothea Kazazi wrote:
> >>
> >> The OSMF board just published a proposal for a software
> >> dispute resolution panel:
> >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
> >> te-resolution-panel/
> >
> > I guess i am asking too much if i envision the board creating a panel it
> > does not control itself...
> >
> > For context - the DWG, which is the traditional and broadly respected
> > entity to resolve conflicts in mapping, is not controlled in
> > composition by the board, it decides on accepting new members
> > themselves.  See also:
> >
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> >
> > Significant parts of the authority the DWG has among mappers derive from
> > the fact that it is not composed of political appointees.
> >
> > Interesting also that the composition of the panel is supposed to
> > reflect "all interests of the OSM community" but competence of the
> > panel members on the subject, experience with and knowledge of mapping
> > and tagging in OSM or in other words:  The competence to assess
> > evidence on the cases they deal with and to deliberate on the matters
> > in a qualified and knowledgable way, is not a criterion.  Neither is
> > impartiality on prominent special interests like those of corporate
> > data users.
> >
> > Transparency is limited to the ultimate decisions being made public
> > (indeed important, would be interesting how this would function
> > otherwise).  I guess that means both the nominations and selection of
> > panel members as well as the deliberation and consulting of the panel
> > on cases is going to happen behind closed doors.
> >
>
> ___
> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Mikel Maron]

Rory, I don't know about you, but I'm certainly hoping for a bunch of corporate 
sell outs rubber stamping iD decisions and squashing the common mapper into 
conformity. Why else would we be doing this?

On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann  
wrote: 





The Board hasn't decided on how the panel will be 
formed/elected/appointed/choosen. Just because the document doesn't 
address one issue, doesn't mean the opposite, horrible option will 
happen. Do you think I'm going to support some Old Boy's Network of 
corporate employees?

What would you suggest for appointing & transparency?

On 04.08.20 21:30, Christoph Hormann wrote:
> On Tuesday 04 August 2020, Dorothea Kazazi wrote:
>>
>> The OSMF board just published a proposal for a software
>> dispute resolution panel:
>> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
>> te-resolution-panel/
> 
> I guess i am asking too much if i envision the board creating a panel it
> does not control itself...
> 
> For context - the DWG, which is the traditional and broadly respected
> entity to resolve conflicts in mapping, is not controlled in
> composition by the board, it decides on accepting new members
> themselves.  See also:
> 
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> 
> Significant parts of the authority the DWG has among mappers derive from
> the fact that it is not composed of political appointees.
> 
> Interesting also that the composition of the panel is supposed to
> reflect "all interests of the OSM community" but competence of the
> panel members on the subject, experience with and knowledge of mapping
> and tagging in OSM or in other words:  The competence to assess
> evidence on the cases they deal with and to deliberate on the matters
> in a qualified and knowledgable way, is not a criterion.  Neither is
> impartiality on prominent special interests like those of corporate
> data users.
> 
> Transparency is limited to the ultimate decisions being made public
> (indeed important, would be interesting how this would function
> otherwise).  I guess that means both the nominations and selection of
> panel members as well as the deliberation and consulting of the panel
> on cases is going to happen behind closed doors.
> 

___
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-fr] Aire du viaduc de Millau

[Gad Jo]

Bonsoir,


En rentrant de Clermont-Ferrand pour aller vers le sud avec une halte à l'aire 
du viaduc de Millau j'ai eu droit à une belle erreur de routage.
J'étais invité à descendre 15km plus au sud en ignorant l'aire pour remonter 
vers le nord et rejoindre l'aire

Après simulation avec Osmand, il s'avère que l'aire est en fait composé de deux 
aires de repos. Les véhicules ne peuvent pas changer d'aire (portail visible à 
fort zoom) mais les piétons peuvent le faire pour admirer le point de vue.
Dans les fait, l'intitulé de l'aire sélectionne celle dans le sens sud-nord. 
Pour l'autre sens il ne faut pas sélectionner l'aire du viaduc de Millau mais 
placer l'étape dans le parking existant au sud.

Sachant qu'on ne tague pas pour le rendu mais que beaucoup d'utilisateur 
peuvent rencontrer la même erreur (j'ai pesté grave et ma chérie a sortie 
GoogleMaps + Waze), comment corriger cela ?
Identifier deux aires ? Sur le terrain il y a qu'un seul nom mais ça à le 
mérite d'être compréhensible
Revoir la géométrie de l'aire pour que le barycentre soit mieux placer ? Pas 
sûr que ça tienne sur le long ou très long terme
Créer une relation ou multipolygone avec un nœud comme centre ? Cela risque de 
complexifier les modifications pour les nouveaux au risque que des doublons 
soient ajouter

Là je sèche... Si vous avez des suggestions je prend

PS : le bug existait l'année dernière mais j'ai accusé les applications sans 
regarder la carte. Cette fois ci j'avais placé un marqueur au sud de l'aire 
(pour le sens nord-sud) mais j'arrivai de l'autre sensm (sud-nord)... Résulta 
je ne m'y suis jamais arrêté à cause d'un gros détour à 5 km au nord pour 
revenir dans le sud Fallait savoir que l'aire était séparée en deux. De 
loin ça à l'aire d'une grosse aire qui n'en manque pas (de l'air)
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Rory McCann]

The Board hasn't decided on how the panel will be 
formed/elected/appointed/choosen. Just because the document doesn't 
address one issue, doesn't mean the opposite, horrible option will 
happen. Do you think I'm going to support some Old Boy's Network of 
corporate employees?


What would you suggest for appointing & transparency?

On 04.08.20 21:30, Christoph Hormann wrote:

On Tuesday 04 August 2020, Dorothea Kazazi wrote:


The OSMF board just published a proposal for a software
dispute resolution panel:
https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
te-resolution-panel/


I guess i am asking too much if i envision the board creating a panel it
does not control itself...

For context - the DWG, which is the traditional and broadly respected
entity to resolve conflicts in mapping, is not controlled in
composition by the board, it decides on accepting new members
themselves.  See also:

https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy

Significant parts of the authority the DWG has among mappers derive from
the fact that it is not composed of political appointees.

Interesting also that the composition of the panel is supposed to
reflect "all interests of the OSM community" but competence of the
panel members on the subject, experience with and knowledge of mapping
and tagging in OSM or in other words:  The competence to assess
evidence on the cases they deal with and to deliberate on the matters
in a qualified and knowledgable way, is not a criterion.  Neither is
impartiality on prominent special interests like those of corporate
data users.

Transparency is limited to the ultimate decisions being made public
(indeed important, would be interesting how this would function
otherwise).  I guess that means both the nominations and selection of
panel members as well as the deliberation and consulting of the panel
on cases is going to happen behind closed doors.



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

[Talk-es] Consulta de la OSMF: reestructuración de la Dirección de Asesoría, financiación del desarrollo de los editores de OSM

[franciscoferiolimarco via Talk-es]

Buenas tardes/noches, envío por primera vez un correo a esta lista. De hecho es 
la primera vez que envío un correo a una lista de correos.

Por sugerencia de un administrador del grupo de Telegram OSM España, envío la 
traducción al español del debate que tuve con algunos miembros de OSM UK en 
Loomio.
Dejo a disposición el enlace para que puedan ver los comentarios originales:
https://www.loomio.org/d/bgUF4wMz/osmf-consultation-advisory-board?discussion_reader_token=qwxYk2C9qMB16DrUocf5i8Hc_campaign=discussion_mailer_medium=email_source=discussion_announced

Mis comentarios intentan responder bajo una misma publicación tanto la consulta 
que se hizo a través del enlace de arriba como la consulta que se hizo en este 
enlace:
https://www.loomio.org/d/nlXVMYmt/osmf-consultations-funding-core-infrastructure?discussion_reader_token=nnMNMYu4guVxV4sRecwZk1v6_campaign=discussion_mailer_medium=email_source=discussion_announced

Como complemento, me parece importante subrayar la estrategia de negocios que 
está llevando adelante Facebook para crear un conjunto de productos que 
trabajen de forma coordinada:

- 2014: adquisición de Oculus VR, un "casco" de realidad virtual.
- 2016: desarrollo de Pytorch mediante su laboratorio de investigación en 
Inteligencia Artificial.
- 2020: adquisición de Mapillary, plataforma de mapas e imágenes 3D 
georreferenciadas, las cuales pueden ser analizadas mediante las tecnologías de 
visión artificial desarrolladas por Mapillary.
- : postulación exitosa para para formar parte de la Dirección de la OSMF.

La lista de arriba es un pequeño resumen/adaptación del artículo que publicó 
Joe Morrison en Medium:
https://medium.com/@joemorrison/why-on-earth-did-facebook-just-acquire-mapillary-9838405272f8

No les parece que la comunidad del software abierto le está cediendo demasiado 
poder a esta empresa que no tiene el más mínimo sentido de la ética?

Pueden ver la traducción del sitio en tiempo real visitando este enlace:
https://translate.yandex.com/translate

Aunque sugiero leer directamente el texto plano traducido por deepl.com, ya que 
las traducciones suelen ser de mayor calidad:

> ---[OpenStreetMap
>  UK](https://www.loomio.org/openstreetmap-uk/), 31 de Julio
>
> Consulta OSMF: Dirección de asesoría
> RobJN · Director · Público · Visto por 40
>
> Hola a todos. Los osmf están consultando sobre los cambios en su junta 
> asesora. Actualmente esto tiene representantes de los capítulos locales (yo 
> para nuestro capítulo local) y representantes de miembros corporativos de 
> oro. La propuesta es dividir esto en dos.
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006984.html
>
> Si desean que les envíe algún comentario, no duden en publicarlo aquí.
>
> Gracias.
>
> ---
>
> Nick · 2 Ago
>
> Dado que los desafíos locales pueden ser bastante diferentes, probablemente 
> tenga sentido dividir la carga de trabajo. En cuanto a los nombres, tal vez 
> las alternativas podrían ser Junta Consultiva Mundial (por ejemplo, visión 
> general estratégica, enfoque en programas grandes, por ejemplo, HOT, normas 
> de datos, etc.) y Juntas Consultivas Locales (lo que es más pertinente para 
> las comunidades locales, enfoque nacional o similar) para reflejar la 
> naturaleza geográfica de los desafíos futuros. Esto también puede ayudar a 
> identificar el nivel de colaboración con diversos organismos, por ejemplo, el 
> GAB trabaja en estrecha colaboración con las organizaciones mundiales de 
> ayuda humanitaria para apoyar sus necesidades. Es posible que cada vez más 
> tengamos que ser conscientes del propósito de hacer mapas y de los aspectos 
> políticos que esto puede implicar. En cuanto a la composición, tiene sentido 
> un enfoque flexible, sobre todo porque la elaboración de mapas se hará más 
> compleja (por ejemplo, el aumento del uso de la IA, los imperativos 
> políticos) y puede exigir que se aporten conocimientos específicos a 
> diferentes niveles. Tiempos interesantes!
>
> ---
>
> Francisco Ferioli Marco · hace 5 horas atrás
>
> No soy del Reino Unido, soy de Argentina, pero como esto tiene que ver con la 
> Junta Internacional, creo que es apropiado compartir mi opinión.
>
> No sé lo que significaría separar la Junta Consultiva de la Junta, pero si el 
> resultado de esto le da a la Junta Consultiva 

Re: [Talk-at] Massenedit von Industriegebieten

[Friedrich Volkmann]

On 31.07.20 03:16, Woazboat wrote:

Mag vielleicht noch jemand einen Blick auf diesen Changeset werfen?

Der User wurde vor zwei Tagen erstellt und editiert seither kreuz und quer
vorrangig Industriegelände auf der halben Welt. Die anderen Changesets dieses
Users sehen, soweit ich das nach kurzem drüberschauen bewerten kann, halbwegs
sinnvoll aus, hier wurden jedoch anscheinend einfach massenhaft man_made=works
Tags in Ost-Österreich gelöscht.


Wenn er das weltweit macht, gehört das der DWG gemeldet, denn es hat keinen 
Sinn einen einzelnen Changeset zu revertieren und überall anders die 
Änderungen zu lassen.


Was er da macht, ist das gleiche, was schon viele vor ihm gemacht haben und 
nach ihm machen werden.


Es gibt da mehrere Kategorien von Massenumtaggern. Eine Kategorie sind 
Leute, die OSM für ein einzelnes Projekt (meist fürs Studium oder beruflich) 
ge-(oder miss-)brauchen. Wenn sie sehen, dass das Tagging uneinheitlich ist, 
taggen sie erst mal alles um, damit sie ihn ihrer Auswertung keine 
unterschiedlichen Tags berücksichtigen müssen.


Eine andere Kategorie sind die Leute, die für diese Art der 
"Qualitätssicherung" von Firmen wie Mapbox bezahlt werden. Die machen den 
ganzen Tag nichts anderes, als fremde Daten umzutaggen.


Dann gibt es noch die "Weltverbesserer", die das aus eigenem Antrieb heraus 
machen, weil ihnen fad ist und sie anders nichts beizutragen wissen.


Typischerweise fängt das damit an, dass sich ein Kartenstil-, Editor- oder 
Validator-Entwickler in den Kopf gesetzt hat, dass ein bestimmtes Tag 
obsolet ist. Wenn die User einer Karte sehen, dass etwas aus der Karte 
verschwindet, oder die User eines Validators eine Fehlermeldung aufblinken 
sehen, gehen sie eifrig daran, die Daten umzutaggen, damit alles wieder 
richtig ausschaut.


Jene User, die wissen, wie man im Wiki editieren kann, schreiben dann auch 
gleich hinein, dass das alte Tagging "deprecated" ist und wie man es jetzt 
richtig macht.


Daraufhin finden sich noch mehr Leute, die die Daten systematisch 
"korrigieren", und im Nu sind von den Millionen Vorkommen in der Datenbank 
fast alle weg.


Wenn man dann versucht, im Wiki eine Diskussion zu starten, wird man darauf 
hingewiesen, dass Taginfo ja beweist, dass das Tag fast nirgends mehr 
vorkommt. Und man ist ja nur ein Nörgler, und man soll aufhören zu streiten, 
sonst wird man gesperrt.


Lange vorbei sind die Zeiten, wo man als Mapper noch was mitzureden hatte 
und über Änderungen demokratisch abgestimmt wurde.


Aber wen wundert das in einer Zeit, wo auch die Rede- und 
Versammlungsfreiheit immer mehr abgeschafft wird.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Frederik Ramm]

Hi,

On 8/4/20 21:30, Christoph Hormann wrote:
> Significant parts of the authority the DWG has among mappers derive from 
> the fact that it is not composed of political appointees.

Speaking as a DWG member, I always hoped that people would judge us by
the work we do, not how we got the job ;)

And about the matter at hand, the DWG has been asked whether they would
like to take on this extra responsibility and we have not yet responded
with anything definitive. On the one hand, this extra job would use more
of our resources and divert them from other important work; on the other
hand, any dispute within the community over editor presets and the like
would sooner or later bubble up to DWG anyway.

If a panel is created that is separate from DWG, we'd definitely have to
build ourselves some safeguards that avoid finding the two bodies on
different sides of a dispute ;)

Bye
Frederik

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

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

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Christoph Hormann]

On Tuesday 04 August 2020, Dorothea Kazazi wrote:
>
> The OSMF board just published a proposal for a software
> dispute resolution panel:
> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
>te-resolution-panel/

I guess i am asking too much if i envision the board creating a panel it 
does not control itself...

For context - the DWG, which is the traditional and broadly respected 
entity to resolve conflicts in mapping, is not controlled in 
composition by the board, it decides on accepting new members 
themselves.  See also:

https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy

Significant parts of the authority the DWG has among mappers derive from 
the fact that it is not composed of political appointees.

Interesting also that the composition of the panel is supposed to 
reflect "all interests of the OSM community" but competence of the 
panel members on the subject, experience with and knowledge of mapping 
and tagging in OSM or in other words:  The competence to assess 
evidence on the cases they deal with and to deliberate on the matters 
in a qualified and knowledgable way, is not a criterion.  Neither is 
impartiality on prominent special interests like those of corporate 
data users.

Transparency is limited to the ultimate decisions being made public 
(indeed important, would be interesting how this would function 
otherwise).  I guess that means both the nominations and selection of 
panel members as well as the deliberation and consulting of the panel 
on cases is going to happen behind closed doors.

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

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Skyler Hawthorne]

Indeed, this is exactly what I was thinking. From an engineering
maintenance perspective, even if you managed to get something
"working", the result would be an incomprehensible mess. I don't
usually like to speak in such extremes, and I certainly don't mean any
offense, but in this case it's warranted: this is a pretty bad idea.

On Tue, 2020-08-04 at 14:08 -0400, Mike Nice wrote:
> On 8/4/2020 7:21 AM, pangoSE wrote:
> > I suggest we wait for ruffle to be ready and then compile P2 to
> > first wasm and then decompile it into C and then translate it into
> > rust.
> > It can then be cleaned up and shipped to both as a desktop
> > application and a wasm binary run in the browser.
> ruffle ->  wasm -> C -> rust is unlikely to be useful. Sure it might 
> run, but all program comments will have been stripped.  The automatic
> C 
> -> Rust step is likely to generate unsafe mode code that must be
> cleaned 
> up to fully see the benefits of Rust.   And finally, the result
> would 
> not be maintainable over the long term without a huge amount of
> cleanup.
> 
> 
> ___
> 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] Proposal for Software Dispute Resolution Panel

[Dorothea Kazazi]

Hello,

The OSMF board just published a proposal for a software
dispute resolution panel:
https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispute-resolution-panel/

.. and is asking for comments and feedback.
Please reply to this message ~ thank you.

warm greetings,
Dorothea
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Mike Nice]

On 8/4/2020 7:21 AM, pangoSE wrote:

I suggest we wait for ruffle to be ready and then compile P2 to first wasm and 
then decompile it into C and then translate it into rust.
It can then be cleaned up and shipped to both as a desktop application and a 
wasm binary run in the browser.
ruffle ->  wasm -> C -> rust is unlikely to be useful. Sure it might 
run, but all program comments will have been stripped.  The automatic C 
-> Rust step is likely to generate unsafe mode code that must be cleaned 
up to fully see the benefits of Rust.   And finally, the result would 
not be maintainable over the long term without a huge amount of cleanup.



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

Re: [OSM-talk-fr] Tag Info France en panne ?

[leni]

Le 04/08/2020 à 18:37, Jocelyn Jaubert a écrit :

Bonjour,

Le souci de nombres incorrects sur http://taginfo.openstreetmap.fr a été
corrigé.

Merci de reporter tout nouveau problème qui pourrait apparaitre


Bonsoir, merci pour la correction

http://taginfo.openstreetmap.fr/search?q=ref%3AFR est passé de 7 pages à 
16, mais me donne 261 éléments


et

https://taginfo.openstreetmap.org/search?q=ref%3AFR%3A 254 éléments

cordialement

leni



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

Re: [Talk-us] Mtb Route Relations

[Nathan Hartley]

 Following this thread.

I have the same question, after recently moving the names that folks had
added to the way (and bridge) segments, of a linear park spanning lower
Michigan, to the relations representing the trail segment. The entire trail
is known as " The Great Lake-to-Lake Trails" [image: relation]
 7962984
, whereas it has segments known by other
names. For instance, 22 miles are also known as the "Mike Levine Lakelands
Trail State Park" [image: relation]
 272564
. I felt this was the most accurate way to
map this trail. However, the temptation is strong to "map for the
renderer", after seeing the trail names disappear from the rendered map
.

On Fri, Jul 31, 2020 at 6:55 PM Mike Thompson  wrote:

> Let's say you have a trail in the US National Forest that was specifically
> created for mountain biking. It has a name and a FS trail number. It is
> represented in OSM by three ways currently: before a bridge, the bridge,
> and after the bridge.
>
> Is this a good candidate for a route relation?
> Should name=* tag appear just on the relation, or on all of the member
> ways as well?
> Should ref=* tag appear just on the relation, or on all of the members as
> well?
>
> I am assuming that physical and legal access tags should only appear on
> the member ways, even if every member has the same value, right?
>
> Just don't want to break anything...
>
> Mike
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Tag Info France en panne ?

[Jocelyn Jaubert]

Bonjour,

Le souci de nombres incorrects sur http://taginfo.openstreetmap.fr a été
corrigé.

Merci de reporter tout nouveau problème qui pourrait apparaitre

-- 
Jocelyn

Le 10/07/2020 à 09:41, Christian Quest a écrit :
> Le 09/07/2020 à 23:36, Christian Rogel a écrit :
>> Je n’ai vu nulle part d’indication sur une panne de TagInfo Fr
>> inaccessible depuis 3 jours.
>> Au niveau mondial, pas souci.
>>
>> Qui a des infos ?
>>
>>
>> Christian R.
> 
> Accessible pour moi, par contre, les chiffres n'ont pas l'air cohérents...
> 
> https://taginfo.openstreetmap.fr/tags a des chiffres qui m'ont l'air
> corrects, dès qu'on demande le détail, tout est à 0...
> 
> 
> Issue ouverte sur: https://github.com/osm-fr/infrastructure/issues/214
> 
> 


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

[OSM-talk] Mapping feature ideas (was: Funding of three infrastructure projects)

[Matthew Woehlke]

On 04/08/2020 11.08, Martin Koppenhoefer wrote:

On 4. Aug 2020, at 16:26, Matthew Woehlke wrote

Obviously, this would all almost surely be a temporary mode (maybe
it persists as long as JOSM is open, but isn't uploaded), but since
you usually draw once, that would be fine. (Bonus points if JOSM
could automatically recreate constraints for ways that don't have
any. It shouldn't be hard to guess equality, perpendicular and
colinear constraints, at least.)


rather than guessing, I sometimes have wished there had been a way to
actually store relationships (geometric) in the data, something like
these buildings all align their front facades, or this door (or
building position) is aligned to this street axis, etc., so when
people moved the street, the building would move as well. Would
become very complex if it would be used extensively (basically you
might move the whole city by moving a node, or it could lead to
unresolvable constraints, etc.), so I think it’s not gonna come. Just
accept some fuzziness ;-)


Sure, I can see the use. I was thinking in terms of things that can be 
done without schema changes.


Besides the troubles of trying to resolve an overconstrained system 
(something I've run into with FreeCAD for systems that are probably much 
more simple than what OSM might become!), another issue is that editors 
that don't support the constraints — I'm looking at iD, mostly because I 
shudder to think of the complexity and performance of implementing a 
solver in a web browser! — will tend to break them often. So, I'm not 
going to hold my breath ;-).



People are overrating rectangular buildings anyway, they might look
more correct than a freehand approximation, but they typically aren’t
(too short, too long, too wide, wrong angle not parallel to the
street, not parallel to their neighbors, etc.), sometimes resulting
from misinterpretation of aerial imagery and conscious or unconscious
generalization (representing with a single rectangle what in reality
is a rectangle with an oriel or a cutting or some other added shape).


Sure, I've seen some overly generalized buildings. I tend to model with 
more detail. (See for example 
https://www.openstreetmap.org/way/44931534, which is also a good example 
of where more constraints would have been useful; there are at least 
three axes of symmetry, and the four corners at the extrema of the 
longer axis *realy* look like they line up.) Still, we *do* tend to 
build things with right angles, so right angles are very often correct. 
At least for buildings. (Roads can easily get more sloppy.)



And sometimes a lack of diligence (e.g. when a building is on the
crossing of two roads which aren’t orthogonal, it is not unlikely
that the building isn’t orthogonal either, and it might be easily
visible in the imagery, but if you only have a hammer, you might be
tempted to use it for the screws as well).


Well, that's a user problem :-). I've also run into many, many instances 
of things that seem like they *ought* to line up, but if aligning is 
noticeably different from the imagery, I won't force it. Most of what 
I'm picky about is within individual buildings, or stuff like aligning 
parking aisles in the middle of the spaces because it renders better and 
the way is (since it's a line, not an area) necessarily an approximation 
anyway.


Conversely, I'll get a little more "sloppy" with placement, because I 
generally trace roof lines and then try to shift the shape to compensate 
for parallax and my best guess at how much the roof overhangs the wall. 
Again, see the previously cited example and compare how it lines up with 
the corners *on the ground* and not the roof line. See the adjacent 
https://www.openstreetmap.org/way/830822584 for an even more pronounced 
example; this one is straddling separate images that were stitched 
together, so there is a discontinuity in the parallax going through the 
middle of it. Constraints actually *help* here because I can make a 
reasoned guess at stuff like "these walls probably line up" and use that 
to try to deduce the actual shape when the imagery is messed up.


Of course, a lot of this will depend on the quality/resolution of the 
imagery available. On the US East Coast, MapBox is very high resolution, 
which help significantly. Trying to map to the level of detail I'm 
typically doing is probably not possible with lower resolution imagery.


--
Matthew

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 04/08/2020 à 15:32, Donat ROBAUX a écrit :

Hello,

Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence 
(et pas que pour ce projet) puisque Geo DAE est en LO donc 
incompatible dans le sens OSM => GeoDEA, alors que des contributeurs 
sont prêts à améliorer les données.


Donat



Cette base n'a pas de fondement contributif volontaire.

1) la loi oblige à fournir les données (mais ne prévoit pas de sanction 
quand on ne le fait pas)


2) seuls les "exploitants" peuvent alimenter la base, et la DGS a 
considéré que cela ne concernait que les propriétaires et pas ceux qui 
assurent la maintenance.


3) rien n'a été mis en place pour du contrôle qualité digne de ce nom*, 
ou alors ça ne fonctionne pas



C'est pas faute d'avoir prêché la bonne parole lors de sa mise en route, 
d'avoir expliqué qu'il fallait aussi collecter ces données auprès des 
sociétés qui assurent la maintenance, car elles savent vraiment où il y 
a des DAE (fonctionnels) et d'avoir poussé pour qu'elle soit en ODbL car 
c'est un vrai commun à construire.


Les propriétaires de bases existantes auraient aussi été rassurés par 
l'ODbL, qui oblige les utilisateurs des données à partager les 
améliorations et donc met un peu tout le monde au même niveau. Ceci 
aurait pu les convaincre de participer au commun.



Je trouve que c'est malheureusement mal parti, je ne sais pas dans 
quelle mesure c'est rattrapable pour avoir une base de qualité et à 
quelle échéance, car là, de ce que j'ai vu, on a une chance sur 4 de 
trouver un DAE là où la base indique qu'il y en a un (et à 100m près). 
Les premiers utilisateurs que sont les SAMU ou pompiers risquent de s'en 
détourner bien vite après quelques échecs... on ne peut faire bonne 
impression qu'une fois, la première ;)


La qualité dépend beaucoup de chaque source. Décathlon semble vraiment 
savoir où sont ses magasins, mais pas Gifi.



Pour convaincre la DGS de notre utilité, il me semble nécessaire de 
commencer par un contrôle qualité de terrain sur un échantillon car 
l'enjeu est plus la qualité que la quantité. La quantité viendra petit à 
petit.


Prenons quelques centaines de DAE dans leur base, autant dans OSM et on 
retourne les vérifier un à un.


Le projet du mois pourrait prioriser l'ajout de survey:date=* et 
permettrait de faire le tri entre des intégrations en fauteuil et du 
mapping de terrain.



* j'ai proposé une correction du modèle de données hier sur les codes 
INSEE des communes, qui étaient décrits comme à 5 chiffres... donc sans 
la Corse (2A/2B).


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 04.08.2020 um 17:05 schrieb Alexandre Oliveira:
>> At this time nobody is proposing anything more than giving P2 a bit more 
>> life for a small sum of money
> And as myself and others have brought up, it's not a good idea to
> spend money to port P2 from a dead technology to another dead
> technology, if people still use it it's much more beneficial in the
> long term to port it to modern web technologies than have to spend a
> few thousand bucks every once in a while to port a software that's
> pretty important for OSM (even though its usage has decreased over the
> years the changeset amount is still high) to another dead technology.
The problem with that is that it implies 2 to 3 more zeros (at least)
before the decimal point in the costs, and -then- the question really
arises why we are doing that. Literally nobody including Richard has
proposed to spend more money down the road, and given that he tends to
be relatively down to earth I assume he is not expecting eternal support.
>
> As someone (I can't recall who it was) said, "$2500 is not much", then
> if the OSMF wants to spend it on useless efforts (i.e. porting P2 from
> Flash to Air) then why not give it to me then, if the OSMF wants to
> spend this money? :P Jokes aside, if the OSMF really wants to spend
> this money I'd suggest it to be spent somewhere else if the board is
> so keen on setting up life support and going through the stress that
> it is to maintain dead libraries.

The reason is that the users want to continue to use P2 for now (see
discussion in the forum for example). To put this in to perspective we
are talking about a one time spend of about 1 € per head, somewhat less
than what iD costs per year (every year), and at least an order of
magnitude less than the same for JOSM etc.

Simon 




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 16:53, Simon Poole  wrote:
> 
> but it isn't a good measure of what the OSMF should spend its money on, weere 
> applying an 80/20 rule is likely to be far more appropriate. 
> 

As I have said, I’m fine with spending 2500 on a dead proprietary technology 
because some long term contributors rely on it and because it’s part of our 
legacy, but only because I’m not applying an 80/20 rule, but an 99/1 rule ;-) 
With an 80/20 approach it would not make sense because there are already a lot 
of alternative editing possibilities available.

> . Definitely nobody is going to embark on the multi-million undertaking that 
> writing and bringing to production a new editor is
> 


you are suggesting that the PL2 development is worth several millions of 
dollars/euros/pounds? Let’s remain serious. Several millions would be tens of 
man-years.

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Philippe Verdy]

Je me demande pourquoi les océans ne pourraient pas être découpés
arbitrairement en cellules plus nombreuses juxtaposées en damier, pour
ensuite réduire cette dépendance à une complexité de plus en plus
exponentielle qu'on accroît la complexité des côtes.
Ne peut-on pas envisager de limiter TOUS les polygones à une bounding-box
maximale, découpée préférablement sur les limites des "quadtiles" ou
limiter le nombre de noeuds qui les définit ? Avantage: une grande partie
des mers serait stable, ultra simple (des carreaux, qu'on redivise
seulement là où c'est nécessaire pour ne pas dépasser cette limite), sans
pour autant augmenter drastiquement le nombre total de polygones pour
dessiner de grande zones (comme la carte du monde).
Cela devrait même être automatisé dans les éditeurs, en élaborant un
nouveau type d'objet (pseudo-relation) groupant les éléments découpés dont
tous les attributs sont communs (strictement aucun attribut sur ces
découpes artificielles, maximisation et renforcement de l'option d'héritage
pour ne plus jamais dupliquer les attributs et simplifier la collecte des
découpes dans un objet collecteur).
Et là je parle de la création d'un nouveau type d'objet "fragment", qui
n'aura JAMAIS aucun autre attribut que la référence à l'objet parent
(non-fragment) qui le référence en liste, de sorte que ces fragments sont
librement réassemblables et optimisables sans jamais avoir à revoir le
"tagging" porté uniquement et strictement dans l'objet principal collecteur
(way fermé ou pas, ou relation multipolygone/multiline). Ces fragments
n'aurait donc aucune autre propriété que leur géométrie "synthétique"
découpée arbitrairement et que n'importe quel outil de dessin/rendu pourra
regrouper librement avec les autres fragments par des opération purement
géométriques simples (d'où des contraintes sur la géométrie des fragments:
les lignes de découpe arbitraires devraient être de simples
horizontales/verticales le long des "quadtiles", et on ne peut assembler
les fragments que s'ils partagent un côté commun qui est sur une ligne de
découpe du quadtile de niveau supérieur.
Cependant on peut imaginer que cette transformation peut se faire sur le
serveur de rendu sans que cela soit visible dans OSM, mais le faire dans
OSM aurait l'avantage d'assurer que les découpes sont recalculées sur la
base elle-même et maintenues de façon synchrone: on ne serait donc plus
obligé de charger les objets entiers mais des fragments et c'est la base
OSM qui s'occupe du réassemblage optimal. Au final on ne travaille alors
plus au niveau global mais toujours localement sur des fragments homogènes
et complets. La gestion des historiques s'en trouve simplifiée, le rendu
aura mois de travail à faire.
La question alors du découpage et du traitement spécial des océans est
oublié: on pourra tout traiter localement sans chercher loin, les requêtes
sont optimisées sur les quadtiles, on peut même avoir un rendu effaice à la
demande et quasi instantané sans traitement complexe car toute la géométrie
nécessaire est localisée. Et plus de problème d'accollement des tuiles
rendues de façon complètement incohérente (même si là on devrait faire
l'effort de mettre fin au rendu bitmap pour avoir des tuiles vectorielles
partout, rendant obolètes les rendus PNG sur quelques gros serveurs
surchargés et jamais à jour).


Le sam. 1 août 2020 à 17:38, Christian Quest  a
écrit :

> Le 26/07/2020 à 23:53, Christian Quest a écrit :
> > Moins de trafic aussi sur les serveurs de l'asso alors c'est le moment
> > des chantiers !
>
> Le chantier continue avec la remise à jour des limites terre/mer et
> l'occupation des sols à petite échelle...
>
>
> Limites terre/mer :
>
> Les natural=coastline mises bout à bout forment d'immenses polygones qui
> sont nécessaires pour avoir la mer en bleu et la terre dans une couleur
> claire par défaut.
>
> Ces polygones sont relativement coûteux à calculer, car composés de très
> nombreux noeuds. Ils sont gigantesques car couvrant des continents entiers.
>
> Du coup, ils sont calculés de temps en temps et mis à disposition sur
> https://osmdata.openstreetmap.de/ sous une forme découpée (oui, façon
> puzzle) avec une version aux géométries simplifiées adaptée aux petites
> échelles.
>
> Les derniers fichiers shapefile dataient de janvier et ils ont été remis
> à jour hier.
>
> Pour le rendu FR, j'en ai profité pour changer la logique car depuis
> toujours, on mettait un fond bleu par défaut et on dessinait les
> continents par dessus.
>
> Or... on calcule bien plus souvent des tuiles sur terre que sur mer,
> donc autant avoir ça de moins à dessiner dans la majorité des cas même
> si c'est sûrement négligeable.
>
>
> L'occupation des sols à petite échelle :
>
> Pour les premiers niveaux de zoom, le rendu FR affiche l'occupation des
> sols (landuse=*). Le problème ici c'est le très grand nombre de
> polygones, parfois très petits et non visibles à ces échelles.
>
> Il y a quelques années, j'avais calculé une couche transparente 

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 16:26, Matthew Woehlke  wrote
> 
> Obviously, this would all almost surely be a temporary mode (maybe it 
> persists as long as JOSM is open, but isn't uploaded), but since you usually 
> draw once, that would be fine. (Bonus points if JOSM could automatically 
> recreate constraints for ways that don't have any. It shouldn't be hard to 
> guess equality, perpendicular and colinear constraints, at least.)


rather than guessing, I sometimes have wished there had been a way to actually 
store relationships (geometric) in the data, something like these buildings all 
align their front facades, or this door (or building position) is aligned to 
this street axis, etc., so when people moved the street, the building would 
move as well. Would become very complex if it would be used extensively 
(basically you might move the whole city by moving a node, or it could lead to 
unresolvable constraints, etc.), so I think it’s not gonna come. Just accept 
some fuzziness ;-)

People are overrating rectangular buildings anyway, they might look more 
correct than a freehand approximation, but they typically aren’t (too short, 
too long, too wide, wrong angle not parallel to the street, not parallel to 
their neighbors, etc.), sometimes resulting from misinterpretation of aerial 
imagery and conscious or unconscious generalization (representing with a single 
rectangle what in reality is a rectangle with an oriel or a cutting or some 
other added shape). And sometimes a lack of diligence (e.g. when a building is 
on the crossing of two roads which aren’t orthogonal, it is not unlikely that 
the building isn’t orthogonal either, and it might be easily visible in the 
imagery, but if you only have a hammer, you might be tempted to use it for the 
screws as well).

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Alexandre Oliveira]

> At this time nobody is proposing anything more than giving P2 a bit more life 
> for a small sum of money

And as myself and others have brought up, it's not a good idea to
spend money to port P2 from a dead technology to another dead
technology, if people still use it it's much more beneficial in the
long term to port it to modern web technologies than have to spend a
few thousand bucks every once in a while to port a software that's
pretty important for OSM (even though its usage has decreased over the
years the changeset amount is still high) to another dead technology.

As someone (I can't recall who it was) said, "$2500 is not much", then
if the OSMF wants to spend it on useless efforts (i.e. porting P2 from
Flash to Air) then why not give it to me then, if the OSMF wants to
spend this money? :P Jokes aside, if the OSMF really wants to spend
this money I'd suggest it to be spent somewhere else if the board is
so keen on setting up life support and going through the stress that
it is to maintain dead libraries.

-- 
Atenciosamente,
Alexandre Oliveira.

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Could we move all the programming language du jour fanboying, apps that
have nothing to do OSM and other unrelated to the topic discussions
somewhere else please?

And yes it underlines my point that regardless of how exotic the feature
is, you are always going to find somebody that finds it critical to
success (this one of the reasons why JOSM has three variants of
everything), but it isn't a good measure of what the OSMF should spend
its money on, weere applying an 80/20 rule is likely to be far more
appropriate.

At this time nobody is proposing anything more than giving P2 a bit more
life for a small sum of money, if Richard has a plan for longer term
maintenance and development then that should be considered when
proposed. Definitely nobody is going to embark on the multi-million
undertaking that writing and bringing to production a new editor is,
just on the base that it would be cool to write one in .

Simon

Am 04.08.2020 um 16:26 schrieb Matthew Woehlke:
> On 04/08/2020 08.10, Martin Koppenhoefer wrote:
>> On 4. Aug 2020, at 13:58, Matthew Woehlke wrote:
>>> but I would practically *kill* for JOSM to have FreeCAD's suite of
>>> sketch constraints ;-).
>>
>> you’re aware that there are sketch constraints for configurable
>> angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle
>> display becomes green)
> Yes. They're better than nothing, but nowhere near what I'm talking
> about. As an example, consider the attached simple FreeCAD sketch
> which is roughly representative of some buildings I've mapped
> recently. The dome in front is centered (segments on either side
> constrained to be equal). The "wings" in back are symmetrical.
>
> It's *possible* to do this sort of thing in JOSM with a lot of care
> and by building part of the geometry, then constructing a bunch of
> "scratch" geometry in order to construct a symmetry line, then doing a
> copy, paste in place, mirror, reverse, stitch the parts together...
> but God help you if you make a mistake and have to start over.
>
> In FreeCAD, you just slap on some equality constraints, angle
> constraints, parallel constraints, etc. and then you can *move* any of
> the nodes and everything else will update to preserve the applied
> constraints. (The one things it's missing that would be helpful is a
> *colinear* constraint; you have to simulate that with parallel and
> coincident constraints using "construction" lines; those are the blue
> ones. A colinear constraint could eliminate the need for those
> construction lines.) This is the major difference, though. In JOSM,
> constraints only apply when you initially draw something, so if you
> get it wrong, you have to start over. In FreeCAD, they're a dynamic
> system; if you get it wrong, just nudge it and the whole thing updates
> *while preserving your constraints*.
>
> Oh, and *arcs*. The ability to define a segment that should be a
> perfect arc, and optionally make it tangent or perpendicular to its
> neighbors, would be a major boon. Again, I can fake it with a bunch of
> scratch construction, but if it's wrong, I have to start over and hope
> my next guess is better. In FreeCAD, just drag the end points until it
> looks right.
>
> Then there are distance constraints, which would be incredibly useful
> if you're mapping something with known dimensions.
>
> Seriously, give FreeCAD a spin. It's pretty awesome for this sort of
> relatively simple 2D stuff. Also look at some of the buildings I've
> done recently; the symmetrical ones don't just *look* symmetrical,
> they *are* symmetrical (within the limits of JOSM's abilities). I've
> also done a lot of stuff like roads that are perfectly centered in
> between parking spaces, groups of aligned buildings that are
> *actually* aligned, and whatnot. It's do-able, but it would be *s*
> much easier with FreeCAD-style constraints.
>
> Obviously, this would all almost surely be a temporary mode (maybe it
> persists as long as JOSM is open, but isn't uploaded), but since you
> usually draw once, that would be fine. (Bonus points if JOSM could
> automatically recreate constraints for ways that don't have any. It
> shouldn't be hard to guess equality, perpendicular and colinear
> constraints, at least.)
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Matthew Woehlke]

On 04/08/2020 08.10, Martin Koppenhoefer wrote:

On 4. Aug 2020, at 13:58, Matthew Woehlke wrote:

but I would practically *kill* for JOSM to have FreeCAD's suite of sketch 
constraints ;-).


you’re aware that there are sketch constraints for configurable
angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle
display becomes green)
Yes. They're better than nothing, but nowhere near what I'm talking 
about. As an example, consider the attached simple FreeCAD sketch which 
is roughly representative of some buildings I've mapped recently. The 
dome in front is centered (segments on either side constrained to be 
equal). The "wings" in back are symmetrical.


It's *possible* to do this sort of thing in JOSM with a lot of care and 
by building part of the geometry, then constructing a bunch of "scratch" 
geometry in order to construct a symmetry line, then doing a copy, paste 
in place, mirror, reverse, stitch the parts together... but God help you 
if you make a mistake and have to start over.


In FreeCAD, you just slap on some equality constraints, angle 
constraints, parallel constraints, etc. and then you can *move* any of 
the nodes and everything else will update to preserve the applied 
constraints. (The one things it's missing that would be helpful is a 
*colinear* constraint; you have to simulate that with parallel and 
coincident constraints using "construction" lines; those are the blue 
ones. A colinear constraint could eliminate the need for those 
construction lines.) This is the major difference, though. In JOSM, 
constraints only apply when you initially draw something, so if you get 
it wrong, you have to start over. In FreeCAD, they're a dynamic system; 
if you get it wrong, just nudge it and the whole thing updates *while 
preserving your constraints*.


Oh, and *arcs*. The ability to define a segment that should be a perfect 
arc, and optionally make it tangent or perpendicular to its neighbors, 
would be a major boon. Again, I can fake it with a bunch of scratch 
construction, but if it's wrong, I have to start over and hope my next 
guess is better. In FreeCAD, just drag the end points until it looks right.


Then there are distance constraints, which would be incredibly useful if 
you're mapping something with known dimensions.


Seriously, give FreeCAD a spin. It's pretty awesome for this sort of 
relatively simple 2D stuff. Also look at some of the buildings I've done 
recently; the symmetrical ones don't just *look* symmetrical, they *are* 
symmetrical (within the limits of JOSM's abilities). I've also done a 
lot of stuff like roads that are perfectly centered in between parking 
spaces, groups of aligned buildings that are *actually* aligned, and 
whatnot. It's do-able, but it would be *s* much easier with 
FreeCAD-style constraints.


Obviously, this would all almost surely be a temporary mode (maybe it 
persists as long as JOSM is open, but isn't uploaded), but since you 
usually draw once, that would be fine. (Bonus points if JOSM could 
automatically recreate constraints for ways that don't have any. It 
shouldn't be hard to guess equality, perpendicular and colinear 
constraints, at least.)


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

[OSM-talk] Celebrate OSM birthday on 2020-08-08

[Jeff McKenna]

Hi all,

I haven't seen OSM's birthday mentioned yet here this year: mark your 
calendars 
https://blog.openstreetmap.org/2020/08/01/celebrate-the-16th-osm-anniversary/


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/






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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Joseph Eisenberg]

We should not ask anyone to do 2 months development work for 2500 euros.

I believe this size grant is only enough for 1 to 2 weeks, based on
international prices (though
I do not have any paid experience in this field)

- Joseph Eisenberg

On Tue, Aug 4, 2020 at 4:08 AM pangoSE  wrote:

> I disagree. For that sum of money I would be willing to start writing a
> new editor in Rust compiled to WebAssembly and desktop and reach a state of
> basic editing useability in 2 months.
> See also https://www.youtube.com/watch?v=ohuTy8MmbLc
> Cheers
>
> Joseph Eisenberg  skrev: (3 augusti 2020
> 01:00:49 CEST)
>
>> While the benefit of making Potlatch 2 on AIR is small, the cost is tiny.
>>
>> 2500 Euros is an insignificant price to pay for supporting an editor
>> which is still used by a couple of thousand long-term users.
>>
>> I support this expenditure.
>>
>> – Joseph Eisenberg
>>
>> On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira 
>> wrote:
>>
>>> I'd like to share my two cents on the matter of supporting Potlatch 2,
>>> an editor built with (now) dead technology.
>>>
>>> I don't think it's worth spending money to update P2 to Air. As others
>>> have stated, Air has been discontinued as well, and it was developed
>>> by Adobe, probably with the same amount of security flaws as Flash
>>> had, which contributed to its demise. I don't see Air as different
>>> even though it's being maintained now by Samsung.
>>>
>>> Just take a look. The web is different than when P2 released; flash is
>>> deprecated and a synonym for vulnerable systems, Air tried to take off
>>> but now it's just another dead technology. What are the benefits of
>>> porting P2 to Air? It may be easier because Air may share some code
>>> with Flash, which in turn makes it easier to port to.
>>>
>>> However, I think that the OSMF should find someone familiar with Flash
>>> and look forward to porting P2 to modern web technologies (please not
>>> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>>> CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
>>> web tech, it doesn't matter. I think it's going to be money well spent
>>> if P2 was ported to a supported web technology and not something that
>>> died a few years ago and is on life support, and barely anyone uses it
>>> nowadays.
>>>
>>> IMO porting P2 to Air is just a waste of money and time from the
>>> developer, and we will reach the same point in the future, be it
>>> either for deprecating P2 or looking to port it to newer web
>>> technologies. OSMF should prepare for the future and not continue
>>> using deprecated technology.
>>>
>>> ___
>>> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Les licences... éternelle prise de tête pour (presque) aucune valeur 
ajoutée ;-) On peut peut-être les convaincre de passer sur l'Odbl, ça 
s'est fait pour les adresses pourquoi pas ici.


Adrien P.

Le 04/08/2020 à 15:32, Donat ROBAUX a écrit :

Hello,

Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence 
(et pas que pour ce projet) puisque Geo DAE est en LO donc 
incompatible dans le sens OSM => GeoDEA, alors que des contributeurs 
sont prêts à améliorer les données.


Donat

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Donat ROBAUX]

Hello,

Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence (et
pas que pour ce projet) puisque Geo DAE est en LO donc incompatible dans le
sens OSM => GeoDEA, alors que des contributeurs sont prêts à améliorer les
données.

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Et c'est d'autant plus intéressant de travailler avec eux maintenant, 
puisque la communauté peut clairement apporter la précision et qualité 
qui manquent actuellement dans la base officielle. Si leur base était 
déjà exhaustive et propre, on aurait plus grand chose à apporter ;-)


J'ai l'impression que la formulation sur le wiki est assez claire pour 
indiquer que l'essentiel du projet du mois est à réaliser par relevé 
terrain (mais ça peut être modifié pour insister davantage si besoin). 
Et donc à discuter avec la DGS (j'ai un appel prévu demain matin) sur 
les aspects alimentation OSM -> GéoDAE, la licence, la possibilité 
d'améliorer le géocodage chez eux en amont, et une communication commune 
sur cette démarche.


Cordialement,

Adrien P.

Le 04/08/2020 à 13:04, Christian Quest a écrit :


A l'aide d'osmose, j'ai exploré les données de GéoDAE pour mon 
département fétiche, l'Yonne... et bien c'est une catastrophe.


Cette base semble essentiellement géocodée, et mal géocodée. Les 
positions sont souvent très mauvaises, il faut absolument la 
re-géocoder proprement en repartant des adresses postales indiquées, 
même si c'est un pis allé par rapport à un lat/lon propre à l'origine.


J'ai contacté par mail les gestionnaires de géodae à ce sujet et pour 
voir comment collaborer. Pour info, j'avais accompagné la DGS au 
démarrage de cette base alors que j'étais à Etalab.



On est donc TRES loin d'une intégration des données GéoDAE, par 
contre, ça peut aider à aller effectivement sur le terrain, ce qui 
d'ailleurs permettrait une remontée sur la qualité auprès de la DGS.


Il y a aussi un sujet annexe... celui de la licence. Aider la DGS à 
améliorer cette base à partir des données OSM ça impose que la base 
soit ensuite diffusées en ODbL... ce que j'avais recommandé.





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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 13:58, Matthew Woehlke  wrote:
> 
> but I would practically *kill* for JOSM to have FreeCAD's suite of sketch 
> constraints ;-).


you’re aware that there are sketch constraints for configurable angles (90, 60, 
45 etc) and projection snaps? Hit 2 times „a“ (angle display becomes green)

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 04/08/2020 à 12:29, PanierAvide a écrit :

Bonjour à tous,

Et si on s'organisait un projet du mois en septembre, par exemple sur 
les défibrillateurs (DAE) ? :-)


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs 



# Pourquoi les défibrillateurs ?

Il y a quelques semaines, la Direction Générale de la Santé a publié 
sa base GéoDAE (en cours de constitution), qui recense les 
défibrillateurs du pays. Un vaste chantier engagé depuis plusieurs 
mois, et qui commence à être visible par ces données. On y compte pour 
l'instant ~15000 défibrillateurs, dont 10% vérifiés par leur opérateur.


En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. 
Évidemment les deux bases ne se recoupent pas, certains DAE sont 
présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. 
Alors si on s'y met en tant que communauté, on a possibilité d'obtenir 
une liste exhaustive sur le territoire de ces équipements !


# Quels sont les objectifs ?

L'objectif principal sera de recenser le plus possible de 
défibrillateur sur le terrain. On pourra ainsi s'aider de la base 
GéoDAE via Osmose et des bases ouvertes par certaines collectivités. 
Mais le gros du travail va consister à arpenter les établissements 
pour retrouver ces équipements. Dans la mesure du possible, on 
renseignera les attributs annexes (localisation, opérateur, niveau...).


# Comment aider à la préparation ?

D'ici le début du projet en septembre, il y a quelques tâches qui 
restent à réaliser, si vous voulez prendre part à l'organisation c'est 
l'occasion !


- Vérifier / compléter la documentation sur le wiki, notamment sur les 
réutilisations existantes de ces données


- Écrire un article pour annoncer le projet du mois sur le site OSM 
France pour publication fin août, de manière générale préparer la 
communication vers l'extérieur sur cette démarche


- Prendre contact avec les groupes locaux OSM, les collectivités 
locales, les assos de secouristes... Toute structure susceptible de 
mobiliser ses membres pour contribuer au projet du mois


Au plaisir de discuter avec vous sur ce projet :-)



A l'aide d'osmose, j'ai exploré les données de GéoDAE pour mon 
département fétiche, l'Yonne... et bien c'est une catastrophe.


Cette base semble essentiellement géocodée, et mal géocodée. Les 
positions sont souvent très mauvaises, il faut absolument la re-géocoder 
proprement en repartant des adresses postales indiquées, même si c'est 
un pis allé par rapport à un lat/lon propre à l'origine.


J'ai contacté par mail les gestionnaires de géodae à ce sujet et pour 
voir comment collaborer. Pour info, j'avais accompagné la DGS au 
démarrage de cette base alors que j'étais à Etalab.



On est donc TRES loin d'une intégration des données GéoDAE, par contre, 
ça peut aider à aller effectivement sur le terrain, ce qui d'ailleurs 
permettrait une remontée sur la qualité auprès de la DGS.


Il y a aussi un sujet annexe... celui de la licence. Aider la DGS à 
améliorer cette base à partir des données OSM ça impose que la base soit 
ensuite diffusées en ODbL... ce que j'avais recommandé.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Matthew Woehlke]

On 04/08/2020 05.30, pangoSE wrote:
On older hardware like my 2 core 2ghz laptop iD is slow. Loading 
while saving an edit is slow, while JOSM is always fast and saving 
does not close the edit view so you can continue without waiting for

a browser to load the iD editor again which is also slow.
I want your JVM :-). I have yet to encounter a Java program (including 
JOSM) that isn't sluggish. (JOSM could be worse, but it's nowhere near 
what I'd expect from a well-written *native* application.)



Matthew Woehlke skrev: (3 augusti 2020 16:14:13 CEST)

(¹ iD can 'square up' individual nodes and does a passable job with
*mostly* orthogonal shapes with the odd 45° angle. There are ways to
work with those in JOSM, but generally speaking if you try to square a
shape with a single 'wild' node, JOSM turns the whole thing into a hot
mess.)


This sounds like a bug. Have you reported it?


Ah... I partially retract that. I think the problem is that I'm trying 
to make it work more like iD which permits *selective* squaring. I 
probably have some nodes selected that's making it go bonkers.


Really, this is a missing feature; I want a way to either square up 
individual nodes, or only angles that are within some delta of 90° 
already (and maybe to snap other angles to e.g. 45°).


Meanwhile, I've gotten better at creating scratch geometry to help with 
construction, but I would practically *kill* for JOSM to have FreeCAD's 
suite of sketch constraints ;-).


--
Matthew

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

Martin Koppenhoefer  skrev: (3 augusti 2020 01:10:09 
CEST)
>
>
>sent from a phone
>
>> On 2. Aug 2020, at 18:11, Guillaume Rischard
> wrote:
>> 
>> As someone who’s listed as having used 9 different editors on
>https://hdyc.neis-one.org/?Stereo (including “unknown”), I know how
>important the variety and richness of editing possibilities is.
>
>
>agreed. Admittedly the stats look pretty bad, user numbers have been
>dropping constantly since 2012, in 2015 there were 24000 PL2 users,
>2016: 14700, 2017 1, 2018 6400, 2019 4900 and 2020 only 2500 so
>far, but I am willing to believe that these are mostly long term and
>hardcore contributors, and 2500 is no big money for the
>OpenStreetMap-Foundation, so it may be worth the effort. At least you
>can be sure that in  these 9,7 million edits no imports are hiding ;-)
>and this number makes it 4th for performed edits.
>
>Cheers Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

mmd  skrev: (2 augusti 2020 11:31:21 CEST)
>On 2020-08-01 12:42, Richard Fairhurst wrote:
>> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle) and
>is
>> under very active development, but does not yet support AS3 or the
>Flash
>> Player features that P2 needs. I would anticipate that P2 will be
>able
>> to run as WebAssembly when Ruffle reaches feature parity with AIR
>2.6.
>
>Yes, exactly, that's one of the two approaches I had in mind: rewriting
>from scratch preferably also in Rust (which obviously wouldn't fit in
>the proposed budget or timeframe), or use Ruffle with the existing
>code.
>

I suggest we wait for ruffle to be ready and then compile P2 to first wasm and 
then decompile it into C and then translate it into rust.
It can then be cleaned up and shipped to both as a desktop application and a 
wasm binary run in the browser.
See 
https://github.com/wwwg/wasmdec
https://github.com/jameysharp/corrode

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 12:28, Andy Townsend  wrote:
> 
> I wrote down what I was there, other people's GPS traces, etc. etc.) and that 
> really needs a desktop editor.


+1, while mobile editors are a great addition to our toolset, they cannot 
substitute desktop editors. A mouse is still much faster and more precise than 
touch input, i.e. for those types of edits where you add or modify a lot of 
geometry, or copy paste information from various sources.

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I disagree. For that sum of money I would be willing to start writing a new 
editor in Rust compiled to WebAssembly and desktop and reach a state of basic 
editing useability in 2 months.
See also https://www.youtube.com/watch?v=ohuTy8MmbLc
Cheers

Joseph Eisenberg  skrev: (3 augusti 2020 01:00:49 
CEST)
>While the benefit of making Potlatch 2 on AIR is small, the cost is
>tiny.
>
>2500 Euros is an insignificant price to pay for supporting an editor
>which
>is still used by a couple of thousand long-term users.
>
>I support this expenditure.
>
>– Joseph Eisenberg
>
>On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira
>
>wrote:
>
>> I'd like to share my two cents on the matter of supporting Potlatch
>2,
>> an editor built with (now) dead technology.
>>
>> I don't think it's worth spending money to update P2 to Air. As
>others
>> have stated, Air has been discontinued as well, and it was developed
>> by Adobe, probably with the same amount of security flaws as Flash
>> had, which contributed to its demise. I don't see Air as different
>> even though it's being maintained now by Samsung.
>>
>> Just take a look. The web is different than when P2 released; flash
>is
>> deprecated and a synonym for vulnerable systems, Air tried to take
>off
>> but now it's just another dead technology. What are the benefits of
>> porting P2 to Air? It may be easier because Air may share some code
>> with Flash, which in turn makes it easier to port to.
>>
>> However, I think that the OSMF should find someone familiar with
>Flash
>> and look forward to porting P2 to modern web technologies (please not
>> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>> CoffeeScript or TypeScript, React, Angular, Vue.js or any other
>modern
>> web tech, it doesn't matter. I think it's going to be money well
>spent
>> if P2 was ported to a supported web technology and not something that
>> died a few years ago and is on life support, and barely anyone uses
>it
>> nowadays.
>>
>> IMO porting P2 to Air is just a waste of money and time from the
>> developer, and we will reach the same point in the future, be it
>> either for deprecating P2 or looking to port it to newer web
>> technologies. OSMF should prepare for the future and not continue
>> using deprecated technology.
>>
>> ___
>> 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-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Bonjour à tous,

Et si on s'organisait un projet du mois en septembre, par exemple sur 
les défibrillateurs (DAE) ? :-)


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs

# Pourquoi les défibrillateurs ?

Il y a quelques semaines, la Direction Générale de la Santé a publié sa 
base GéoDAE (en cours de constitution), qui recense les défibrillateurs 
du pays. Un vaste chantier engagé depuis plusieurs mois, et qui commence 
à être visible par ces données. On y compte pour l'instant ~15000 
défibrillateurs, dont 10% vérifiés par leur opérateur.


En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. 
Évidemment les deux bases ne se recoupent pas, certains DAE sont 
présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. 
Alors si on s'y met en tant que communauté, on a possibilité d'obtenir 
une liste exhaustive sur le territoire de ces équipements !


# Quels sont les objectifs ?

L'objectif principal sera de recenser le plus possible de défibrillateur 
sur le terrain. On pourra ainsi s'aider de la base GéoDAE via Osmose et 
des bases ouvertes par certaines collectivités. Mais le gros du travail 
va consister à arpenter les établissements pour retrouver ces 
équipements. Dans la mesure du possible, on renseignera les attributs 
annexes (localisation, opérateur, niveau...).


# Comment aider à la préparation ?

D'ici le début du projet en septembre, il y a quelques tâches qui 
restent à réaliser, si vous voulez prendre part à l'organisation c'est 
l'occasion !


- Vérifier / compléter la documentation sur le wiki, notamment sur les 
réutilisations existantes de ces données


- Écrire un article pour annoncer le projet du mois sur le site OSM 
France pour publication fin août, de manière générale préparer la 
communication vers l'extérieur sur cette démarche


- Prendre contact avec les groupes locaux OSM, les collectivités 
locales, les assos de secouristes... Toute structure susceptible de 
mobiliser ses membres pour contribuer au projet du mois


Au plaisir de discuter avec vous sur ce projet :-)

--
Adrien P.


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Andy Townsend]

On 04/08/2020 11:19, pangoSE wrote:
I would recommend you to use another way to archive this. Open OsmAnd 
on your phone and add a POI directly. You can add tags too if you 
remember them. Then upload directly to OSM.

No JOSM or GPX file handling neccesary.

I use Vespucci for exactly that (no, I'm not on commission - other 
mobile editors are available!) but often you need to take information 
from all sorts of different sources (imagery, my GPS information, what I 
wrote down what I was there, other people's GPS traces, etc. etc.) and 
that really needs a desktop editor.


Best Regards,

Andy



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

Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Tomas Straupis]

> In the absence of other proposals, even splitting it among the other two 
> would be a much better use, in my opinion.

  Chrm. iD gets the pile of money and the MAIN OpenStreetMap editor -
JOSM - gets NOTHING?
  Or does this show that iD is so broken/unwanted that nobody wants to
work on it without getting paid a lot?

-- 
Tomas

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I would recommend you to use another way to archive this. Open OsmAnd on your 
phone and add a POI directly. You can add tags too if you remember them. Then 
upload directly to OSM.
No JOSM or GPX file handling neccesary.

Andy Townsend  skrev: (3 augusti 2020 00:09:44 CEST)
>On 02/08/2020 22:52, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>>> On 2. Aug 2020, at 17:09, Andy Townsend  wrote:
>>>
>>> GPX track waypoint handling is the biggest missing piece of 
>>> functionality for me, so you can start with that one if you wish
>>
>>
>> I guess this is about not handling symbols?
>
>Not really - see 
>https://help.openstreetmap.org/questions/6368/in-josm-is-it-possible-to-see-gpx-track-waypoint-details
>
>for information.
>
>If there's a better answer available now (which is entirely possible -
>I 
>asked that question 9 years ago!) then I'd suggest adding it at that 
>help question.  See also 
>https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node
>
>which is somewhat similar.
>
>Best Regards,
>
>Andy
>
>
>
>___
>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] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I agree with this. 

Particularly Rust compiled to WebAssembly look very promising for building 
applications like an editor. Rust is fast and safe and it already has multiple 
OSM related crates. 
See here for an example: https://www.youtube.com/watch?v=YHJjmsw_Sx0

An editor written in Rust and compiled to WebAssembly would probably be a lot 
faster than iD is today. 
Writing something completely in browser JS these days is not the best way 
forward if speed and portability is is important iMO.

Alexandre Oliveira  skrev: (2 augusti 2020 19:01:23 CEST)
>I'd like to share my two cents on the matter of supporting Potlatch 2,
>an editor built with (now) dead technology.
>
>I don't think it's worth spending money to update P2 to Air. As others
>have stated, Air has been discontinued as well, and it was developed
>by Adobe, probably with the same amount of security flaws as Flash
>had, which contributed to its demise. I don't see Air as different
>even though it's being maintained now by Samsung.
>
>Just take a look. The web is different than when P2 released; flash is
>deprecated and a synonym for vulnerable systems, Air tried to take off
>but now it's just another dead technology. What are the benefits of
>porting P2 to Air? It may be easier because Air may share some code
>with Flash, which in turn makes it easier to port to.
>
>However, I think that the OSMF should find someone familiar with Flash
>and look forward to porting P2 to modern web technologies (please not
>Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
>CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
>web tech, it doesn't matter. I think it's going to be money well spent
>if P2 was ported to a supported web technology and not something that
>died a few years ago and is on life support, and barely anyone uses it
>nowadays.
>
>IMO porting P2 to Air is just a waste of money and time from the
>developer, and we will reach the same point in the future, be it
>either for deprecating P2 or looking to port it to newer web
>technologies. OSMF should prepare for the future and not continue
>using deprecated technology.
>
>___
>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] Mazání starých uzavírek

[Marián Kyral]

Jak přesně se to implementuje je na diskusi. Kolik toho je celosvětově
netuším. To by se musela udělat nějaká analýza. Možná toho není tolik, ale
třeba by to stálo za to. Už jen proto, že se pak stará data nepletou do
spracování, není potřeba je stahovat a následně zahazovat.





Marián



-- Původní e-mail --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 4. 8. 2020 9:57:06
Předmět: Re: [talk-cz] Mazání starých uzavírek
"
Opatrně s tím fullauto módem...je toho tolik, aby to muselo běžet
celosvětově a bez kontroly? Medle tenhle postup "stroj udělá změny, člověk
po kontrole commitne changeset" se celkem osvědčil... různý nečekaný stavy
vylezou až po delším provozu.



Zdar,

HPM




Dne út 4. 8. 2020 7:05 uživatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ona třeba tahle činnost by mohla být vykonávána automaticky pro celý svět.
Že by se o to starala DWG.





Marián

-- Původní e-mail --
Od: Jan Macura mailto:macura...@gmail.com)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 3. 8. 2020 23:55:20
Předmět: Re: [talk-cz] Mazání starých uzavírek
"Ahoj,

taky souhlasím. Na tyhle opakující se rutinní činnosti by to chtělo (řečí
Wikipedie) robotický účet...

H.

On Monday, 3 August 2020, majka mailto:majka.zem%2bt...@gmail.com)> wrote:
> Není třeba. Už to mám komplet připravené, porovnávám přímo s aktuálním
datem.
> Vypadá to, že nejsou námitky, tak ještě počkám do rána a zítra to spustím.
> Majka
> On Mon, 3 Aug 2020 at 18:27, Milan Cerny mailto:milan...@centrum.cz)> wrote:
>>
>> Ahoj, jo jo, zase to urodilo. Příležitostně to promažu. Kdyby měl někdo
chuť se do toho pustit hned, tak OT query z minula by mohlo pomoci.
>>
>> https://overpass-turbo.eu/s/IbK(https://overpass-turbo.eu/s/IbK)
>>
>> Stačí jen přepsat poslední rok.
>>
>> Milan
>>
>

--
Sent from phone
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

Hi

Matthew Woehlke  skrev: (3 augusti 2020 16:14:13 CEST)
>On 02/08/2020 06.05, Simon Poole wrote:
>
>I'm not saying iD is *bad*. It's a very nice editor *for its 
>capabilities*. It's great for making *small* changes or introducing 
>someone to OSM editing... but there are a lot of use cases still where 
>JOSM is just a far superior tool. Maybe in *5-10* years that will 
>change, but I'm not going to hold my breath on it overtaking JOSM in
>1-2.

On older hardware like my 2 core 2ghz laptop iD is slow. Loading while saving 
an edit is slow, while JOSM is always fast and saving does not close the edit 
view so you can continue without waiting for a browser to load the iD editor 
again which is also slow.

>
>(¹ iD can 'square up' individual nodes and does a passable job with 
>*mostly* orthogonal shapes with the odd 45° angle. There are ways to 
>work with those in JOSM, but generally speaking if you try to square a 
>shape with a single 'wild' node, JOSM turns the whole thing into a hot 
>mess.)

This sounds like a bug. Have you reported it?

Cheers 
pangoSE

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

Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[pangoSE]

I agree.

Skyler Hawthorne  skrev: (2 augusti 2020 19:30:09 CEST)
>In the absence of other proposals, even splitting it among the other
>two would be a much better use, in my opinion.
>
>--
>Skyler
>
>
>On Sun, Aug 2, 2020, at 13:27, Rory McCann wrote:
>> On 02.08.20 01:03, Skyler Hawthorne wrote:
>> > Sorry if this sounds harsh, but I think using any funds at all to 
>> > continue support for a tool that 1% of editors use would be
>wasteful. 
>> > Flash is, for all intents and purposes, a dead technology. This
>money is 
>> > better spent on other uses.
>> 
>> What would you suggest?
>> 
>> Serious question. We're suggesting spending €2,500 on this. Where
>else 
>> do you suggest spending €2,500 on?
>> 
>> Rory
>> 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-cz] Mazání starých uzavírek

[Jan Martinec]

Opatrně s tím fullauto módem...je toho tolik, aby to muselo běžet
celosvětově a bez kontroly? Medle tenhle postup "stroj udělá změny, člověk
po kontrole commitne changeset" se celkem osvědčil... různý nečekaný stavy
vylezou až po delším provozu.

Zdar,
HPM

Dne út 4. 8. 2020 7:05 uživatel Marián Kyral  napsal:

> Ona třeba tahle činnost by mohla být vykonávána automaticky pro celý svět.
> Že by se o to starala DWG.
>
> Marián
> -- Původní e-mail --
> Od: Jan Macura 
> Komu: OpenStreetMap Czech Republic 
> Datum: 3. 8. 2020 23:55:20
> Předmět: Re: [talk-cz] Mazání starých uzavírek
>
> Ahoj,
>
> taky souhlasím. Na tyhle opakující se rutinní činnosti by to chtělo (řečí
> Wikipedie) robotický účet...
>
> H.
>
> On Monday, 3 August 2020, majka  wrote:
> > Není třeba. Už to mám komplet připravené, porovnávám přímo s aktuálním
> datem.
> > Vypadá to, že nejsou námitky, tak ještě počkám do rána a zítra to
> spustím.
> > Majka
> > On Mon, 3 Aug 2020 at 18:27, Milan Cerny  wrote:
> >>
> >> Ahoj, jo jo, zase to urodilo. Příležitostně to promažu. Kdyby měl někdo
> chuť se do toho pustit hned, tak OT query z minula by mohlo pomoci.
> >>
> >> https://overpass-turbo.eu/s/IbK
> >>
> >> Stačí jen přepsat poslední rok.
> >>
> >> Milan
> >>
> >
>
> --
> Sent from phone
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Mazání starých uzavírek

[majkaz]

Tak hotovo, sada změn https://www.openstreetmap.org/changeset/88913147 
 . Nahráno pod mým importním 
účtem.
 
Můžu to dělat pravidelně, třeba současně se schránkami (dnes konečně má pošta 
data nového měsíce, včera ještě nebyla).
 
U těch uzavírek jde ta největší práce jde udělat automaticky, stačí pak jen 
zkontrolovat všechy hodnoty vehicle:conditional, co mi to vybere, aby tam 
nebylo ještě něco navíc, nejen uzavírka kvůli stavbě.
 
Majka
 
 
__
> Od: "Jan Macura" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 03.08.2020 23:52
> Předmět: Re: [talk-cz] Mazání starých uzavírek
>
Ahoj,

taky souhlasím. Na tyhle opakující se rutinní činnosti by to chtělo (řečí 
Wikipedie) robotický účet...

H.


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

Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un aire urbaine imaginaire ?

[Romain MEHUT]

Oui aussi pourquoi pas mais je me pose quand même la question de la source 
utilisée pour ajouter autant de panneaux.



Romain


De : Gad Jo 
À : Discussions sur OSM en français ;
   Romain MEHUT ;
   talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un aire urbaine 
imaginaire ?
Date : 04/08/2020 07:28:31 Europe/Paris

Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette anomalie 
vers Osmose pour ajouter un nouveau contrôle ?

Je suis sûr que d'autre contributeur en ont créé de la même façon et qu'il 
pourraient bénéficier de ce type de correction.
Au passage ça évite les suppression accidentelle de nœud où d'autres tag 
seraient ajoutés (honnêtement ça m'étonnerait mais autant prévoir).

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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

[osm . sanspourriel]

> Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette
anomalie vers Osmose pour ajouter un nouveau contrôle ?

Peut-être parce que la seule possibilité c'est de supprimer cette infox.

Sur les 4639 points ajoutés par notre ami, approximativement 703 sont
sur des highway (703 routes passent par ces points).

Concernant 4 000 points environ : on a l'information que le contributeur
a estimé que la limite urbaine c'était par là (au vue d'une imagerie
_aérienne_ comme si les limites correspondaient forcément !).

Absolument pas parce qu'il y a un panneau là.

Donc tu fais quoi ? Tu regardes une imagerie de rue pour voir s'il y a
un panneau dans le coin ?

Non, supprimer ces 4 000 points c'est hélas la bonne solution.

À ne pas confondre avec le cas de Florian (il a vu le panneau et a mis
la limite non au niveau de la route mais au niveau du panneau, il peut
mettre à jour sans problème).

Jean-Yvon


Le 04/08/2020 à 07:28, Gad Jo - perche...@toutenkamion.net a écrit :



Je suis sûr que d'autre contributeur en ont créé de la même façon et
qu'il pourraient bénéficier de ce type de correction.
Au passage ça évite les suppression accidentelle de nœud où d'autres
tag seraient ajoutés (honnêtement ça m'étonnerait mais autant prévoir).

Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT
 a écrit :

Je viens d'envoyer un message par la messagerie interne d'osm.org.
J'attends donc encore un peu avant de passer au
traffic_sign=city_limit.

Romain


De : Christian Quest 
À : talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un
aire urbaine imaginaire ?
Date : 03/08/2020 09:00:10 Europe/Paris

Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
> Les hésitations ont trop duré, c'est souvent le problème dans
OSM, on
> n'ose pas toujours pour ne pas froisser des susceptibilités. Je
n'ai
> rien contre le tag boundary=urban, c'est juste que dans le cas
> présent, son emploi s'est fait sans tenir compte des données déjà
> présentes...
>
> Romain
>
Pour ça que la première chose à faire est de prendre contact avec le
contributeur avant de faire la modification massive, surtout
quand c'est
un régulier comme ici.


--
Christian Quest - OpenStreetMap France


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



--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
brièveté.

___
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