Re: [talk-ph] Strava Heatmap

[Jim Morgan]

Eugene Alvin Villar wrote on Tuesday, 21 November, 2017 01:52 PM:
> I find it more useful for aligning imagery. :)

Interesting. I know how to align the background imagery in OSM to the GPS 
traces within OSM. But how would you do it using an external source like this? 
Just in case I need it sometime ... 

Jim

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

Re: [OSM-talk] What would make MapRoulette better?

[joost schouppe]

Hi Erwin,
This is entirely posible in Osmose. See for example:

http://osmose.openstreetmap.fr/fr/map/#item=8120=13=44.8202=-0.5935=Mapnik=T=1%2C2%2C3==

2017-11-21 4:08 GMT+01:00 Erwin Olario :

> So sorry for the terse reply.
>
> Right now, the only way to build task is to specify the location or
> specific objects.
>
> The use-case I have in mind is when a data provider allows or donates
> their data into OSM, and apart from geographic location and geometry, they
> have specific attributes usable in OSM.
>
> For example, a local school department gives the local OSM community
> permission to use their school location data that includes the official
> school name (which may be missing or incomplete in the current database),
> and contact number, and official website. And instead of doing a bulkl
> import, and using MR, the data are presented to the MR contributor to be
> merged or added into OSM.
>
> In this example the tags: name, contact:phone, contact:website are added
> to the specific tasks of the challenge.
>
> /Erwin
>
>
>
> On Tue, Nov 21, 2017 at 12:36 AM Martijn van Exel  wrote:
>
>> Hi Erwin,
>>
>> Can you give an example of what you would like to see and how you would
>> like it to work?
>>
>> --
>> Martijn van Exel
>>
>> On November 20, 2017 at 6:30:01 AM, Erwin Olario (gov...@gmail.com)
>> wrote:
>>
>>
>> I wish to see support for OSM tags for tasks.
>>
>> On Mon, Nov 20, 2017 at 5:02 AM Martijn van Exel  wrote:
>>
>>> Hi all,
>>>
>>> For those who have used MapRoulette or at least have a good
>>> understanding of what it does: what would be the *one top thing* for you
>>> that would make it better?
>>>
>>> I am asking because I am working on a new major release.
>>> --
>>> Martijn van Exel
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>> --
>>
>> /Erwin Olario
>>
>> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
>> https://mstdn.io/@GOwin
>>
>> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk] What would make MapRoulette better?

[joost schouppe]

Martijn,
Maproulette does give hashtags to ID changesets using the changeset comment
right now. There are tools like osmcha or Pascal Neis's osm-changesets to
easily filter them. A dedicated tag might of course help find "anything
that started with a QA tool", which is then filter-able by tool and/or
Challenge.

2017-11-20 22:49 GMT+01:00 Bryan Housel :

> Hey Martijn, it’s currently possible to send comments and hashtags to iD
> (they can be sent as two different parameters, or just embed the hashtags
> in the comments like the task managers currently do).  It’s not possible to
> set other changeset tags, but it is something I could add if there is a
> good use case for it.
>
> Thanks, Bryan
>
>
>
> > On Nov 20, 2017, at 4:44 PM, Martijn van Exel  wrote:
> >
> > Hi Pierre,
> >
> > That is a good idea and there are already some ‘hashtags’ that
> MapRoulette sends to JOSM. I don’t know if this is possible in iD as well.
> I think it is something that could be improved upon. Perhaps with changeset
> tags (is that what you are suggesting?)
> >
> > Does anyone know if JOSM and / or iD support ‘sending’ changeset tags
> through remote control / the querystring?
> >
> > Martijn
> >
> > --
> > Martijn van Exel
> >
> > On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr)
> wrote:
> >> Hi Martijn
> >> We see an increase of coordinatead actions via QA and TM tools. But
> this is not systematically
> >> documented on the Changeset metadata. For QA tools, sometimes we see in
> the comments
> >> reference to MapRoulette or other tools.
> >> It is possible for these tools to transfer infos to editors such as iD
> and JOSM. It would
> >> be good that tags are transferred to the editors to better document the
> coordinated actions.
> >> For TM tools, it could be host and project_no / Title. For QA, it could
> be host and project.
> >> For Maroulette this could beQA=MaprouleteProject=XXX where XXX
> corresponds to a particular
> >> challenge.
> >>
> >> Pierre
> >>
> >>
> >> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
> >>
> >> Marc,
> >>
> >> Good point and something that has come up often.
> >> As Joost mentioned in a reply, the easy solution for this is, as a
> challenge owner, to split
> >> up the challenge into regional chunks and label them as such.
> >>
> >> The new version will have ‘filter by current map bounds’. I’m not quite
> sure how to best
> >> do this yet. One solution would be to filter by challenge ‘centroids’
> (simple), another
> >> would be to consider whatever challenge has at least one task within
> the current map bounds
> >> (harder). What would be your idea about this? Others with an opinion?
> >> --
> >> Martijn van Exel
> >>
> >> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com)
> wrote:
> >>> The possibility to work more locally. E.g. there is a project to add
> >>> missing roads in Belgium, I would really like to see only the "issues"
> >>> within let say 20km of my house (an arbitrary point I can set).
> >>>
> >>> m.
> >>>
> >>> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
>  Hi all,
> 
>  For those who have used MapRoulette or at least have a good
> understanding of
>  what it does: what would be the *one top thing* for you that would
> make it
>  better?
> 
>  I am asking because I am working on a new major release.
>  --
>  Martijn van Exel
> 
>  ___
>  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
>



-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

[OSM-talk-ie] Luas Cross City

[Colm Moore]

Hi,


This is due to open on 9 December 2017. The entire railway is in place and the 
remaining works are things like ticket validators, signage, depot / substation 
works, tidying up, etc.


When should the railway be changed from railway=construction to railway=tram?

Stops are currently named "stop_name (November 2017)". Should this be changed 
to "stop_name (December 2017)".

I'm going to see if I can get a trip before opening day - would anyone like to 
come along? Having someone with a battery powered dash cam (or two - one with / 
without audio) and a GPS unit would be good.


Colm


---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-ja] 歩道のマッピング

[Mariko HISAKAWA/GODA]

ごうだまりぽ (id:maripogoda)と申します。
秋葉原〜湯島付近でぼちぼち歩道を描きはじめているのですが、いろいろと悩みどころも
多いです。
「縁石と歩道の主線をつなぐ部分」や点字ブロックについての疑問です。

> しかしながら、歩道は安全ゾーンで、縁石から先が危険ゾーンというのが
> 特に障害をお持ちの方にはある感覚なので、
> 横断歩道はこちらの縁石から向こうの縁石まで
> と案内できるようにデータを作っておくのがベターではないでしょうか。
> 横断歩道(縁石)の手前に点字ブロックがある場合はこの問題になっている部分に
> tactile_paving=yesタグが付加されます。

「歩道全体に点字ブロックがあるわけではないが、歩道の曲がり角と横断歩道の手前だけに点字
ブロックが設置されている」というパターンをよく見かけますが、その場合は「縁石と歩道の
主線をつなぐ部分」と「横断歩道の曲がり角」をつなげたものを1つのウェイにして
tactile_paving=yesを付与し、歩道の直線部分はtactile_paving=noを付与する……というのが
適切なのでしょうか。

また、Wikiを見たところ、縁石ノードにtactile_pavingをつけるケースも有るとのことですが、
https://wiki.openstreetmap.org/wiki/Key:kerb
横断歩道の手前の縁石に沿って点字ブロックがある場合、「縁石と歩道の主線をつなぐ部分」の
ウェイと縁石ノード両方にtactile_paving=yesを付けたほうがいいのでしょうか。


--
Maripo GODA/ ごうだまりぽ
goda.mar...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Wiki OSM : fusion des catégories FR:Randonnée et FR:Marche à pied

[Jean-Christophe Becquet]

Bonjour,

Je comprends les arguments de Christian R. et Philippe donc je ne touche
pas aux catégories FR:Randonnée et FR:Marche à pied :

 https://wiki.openstreetmap.org/wiki/Category:FR:Randonn%C3%A9e
https://wiki.openstreetmap.org/wiki/Category:Hiking en anglais

 https://wiki.openstreetmap.org/wiki/Category:FR:Marche_%C3%A0_pied
https://wiki.openstreetmap.org/wiki/Category:Walking en anglais

Bonne journée

JCB
-- 
La suite bureautique Libreoffice
http://www.apitux.org/index.php?2006/07/11/3-la-suite-bureautique-libreoffice

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

[talk-ph] Fwd: [Osmf-talk] Directed Editing Policy

[Eugene Alvin Villar]

Heads up. The Data Working Group is aiming to develop a policy to govern
directed editing in OSM.

Comments and suggestions are welcome.
-- Forwarded message --
From: "Frederik Ramm" 
Date: Nov 21, 2017 8:56 AM
Subject: [Osmf-talk] Directed Editing Policy
To: "osmf-t...@openstreetmap.org" 
Cc:

Hi,

   the DWG has prepared a policy on "Directed Editing" (former working
title "Organised Editing Policy"). Read it here:

https://wiki.osmfoundation.org/wiki/Directed_Editing_Policy

The policy picks up (but doesn't slavishly follow) the results of our
survey, where it became obvious that transparency and communications are
what mappers find most important about organised mapping efforts. The
policy replaces the somewhat fuzzy terms of "paid" and "organised"
editing with the concept of "directed editing", which is essentially
when you're required to edit OSM (because of work, a school assignment
etc) and/or when you're told by others exactly what and how to map.

The DWG is interested in feedback on this proposal. Are you currently
involved in some form of editing that would be covered by the policy?
Does the policy present an unnecessary obstacle for some activities? If
you have witnessed organised mapping efforts that caused problems -
would these problems have been avoided if people had adhered to the
proposed policy?

Bye
Frederik

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

___
osmf-talk mailing list
osmf-t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osmf-talk
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[talk-ph] Strava Heatmap

[Jim Morgan]

Just of general mapping interest. 
https://labs.strava.com/heatmap/#13.42/121.01607/14.56427/hot/ride

Can use it to see where people cycle, run, etc. 

Jim

-- 

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

Re: [OSM-talk] What would make MapRoulette better?

[Marc Gemis]

Martijn,

I'll agree with Yuri that is has to be the choice of the mapper to
work in a specific region and not the challenge creator. I don't want
to ask each challenge creator to split up the challenge in smaller
chunks, just because I feel uncomfortable editing outside a certain
area. This area can also be different from challenge to challenge and
from mapper to mapper.

You already have a view where you show the individual tasks within a
challenge. One can pick a task from this view right now, but after
marking the task as completed, a completely random one is chosen
again.

For me, it would be sufficient to have a button/switch on the screen
with all individual tasks that switches to "only tasks from the
current bounding box". Would that be feasible ?

m.

On Mon, Nov 20, 2017 at 9:48 PM, Martijn van Exel  wrote:
> Marc,
>
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
> owner, to split up the challenge into regional chunks and label them as such.
>
> The new version will have ‘filter by current map bounds’. I’m not quite sure 
> how to best do this yet. One solution would be to filter by challenge 
> ‘centroids’ (simple), another would be to consider whatever challenge has at 
> least one task within the current map bounds (harder). What would be your 
> idea about this? Others with an opinion?
> --
> Martijn van Exel
>
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
>> The possibility to work more locally. E.g. there is a project to add
>> missing roads in Belgium, I would really like to see only the "issues"
>> within let say 20km of my house (an arbitrary point I can set).
>>
>> m.
>>
>> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
>> > Hi all,
>> >
>> > For those who have used MapRoulette or at least have a good understanding 
>> > of
>> > what it does: what would be the *one top thing* for you that would make it
>> > better?
>> >
>> > I am asking because I am working on a new major release.
>> > --
>> > Martijn van Exel
>> >
>> > ___
>> > 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] What would make MapRoulette better?

[Erwin Olario]

So sorry for the terse reply.

Right now, the only way to build task is to specify the location or
specific objects.

The use-case I have in mind is when a data provider allows or donates their
data into OSM, and apart from geographic location and geometry, they have
specific attributes usable in OSM.

For example, a local school department gives the local OSM community
permission to use their school location data that includes the official
school name (which may be missing or incomplete in the current database),
and contact number, and official website. And instead of doing a bulkl
import, and using MR, the data are presented to the MR contributor to be
merged or added into OSM.

In this example the tags: name, contact:phone, contact:website are added to
the specific tasks of the challenge.

/Erwin



On Tue, Nov 21, 2017 at 12:36 AM Martijn van Exel  wrote:

> Hi Erwin,
>
> Can you give an example of what you would like to see and how you would
> like it to work?
>
> --
> Martijn van Exel
>
> On November 20, 2017 at 6:30:01 AM, Erwin Olario (gov...@gmail.com) wrote:
>
>
> I wish to see support for OSM tags for tasks.
>
> On Mon, Nov 20, 2017 at 5:02 AM Martijn van Exel  wrote:
>
>> Hi all,
>>
>> For those who have used MapRoulette or at least have a good understanding
>> of what it does: what would be the *one top thing* for you that would make
>> it better?
>>
>> I am asking because I am working on a new major release.
>> --
>> Martijn van Exel
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
> --

/Erwin Olario

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

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Pierre Béland]

Bonjour Charles,
Je suis en contact avec le responsable de McGill. Effectivement, dans leurs cas 
ils prévoient réviser le travail avec les étudiants.
Par contre dans le cadre de Mapathons, il est important de prévoir en général 
de bien sopporter les nouveaux contributeurs. Il me semble important d'avoir 
des outils de suivi des contributions et corriger très rapidement les 
problèmes. Des requêtes Overpass peuvent être utilisées pour suivre l'ensemble 
du groupe ou des contributeurs individuels. La possibilité de projeter sur 
écran peut aussi grandement faciliter l'interaction avec les participants.


 
Pierre 
 

Le lundi 20 novembre 2017 21:17:42 HNE, Charles Basenga Kiyanda 
 a écrit :  
 
 Bonjour Pierre,

Juste quelques précisions car j'ai été impliqué dans une de ces activités. Dans 
le cas de Williams Lake (projet 91), il a été utilisé pour un mapathon d'un 
nouveau groupe (Open Mapping Group McGill). C'est un nouveau groupe, mais qui 
me semble très bien organisé. Il ya eu trois présentations qui, en tout,, ont 
duré environ 1h15,, avant que les participants se mettent à contribuer. 

Le projet sur le gestionnaire de tâches à été créé par Julia Conzon (sp?) de 
Mapbox qui a donné une des conférences par vidéo. J'assume que c'est 
l'utilisateur noznoc.

Pour ce qui est de cet événement en particulier, c'est vrai que la partie 
validation tarde, mais je crois bien qu'elle se fera. Leur groupe semble très 
bien organisé. Il émane surtout du département de géographie avec un bon 
support de membres du personnel. 

Je n'extrapolerai pas aux autres activités et je commentterai pas sur les 
techniques de Mapbox, mais pour ce qui est de l'activité à McGill liée à 
williams Lake, c'était une activité bien organisée.

Maintenant, il reste à structurer la validation des données. C'est sûr que sans 
l'urgence d'un projet HOT, c'est plus difficile de motiver les gens à continuer 
leur implication.

Charles

On November 20, 2017 8:56:18 PM EST, "Pierre Béland"  wrote:
John
Je t'ai informé précédemment que je constatais pour Calgary des doublons 
d'adresse, celle-ci était ajoutée à la fois sur l'immeuble principal et le 
garage. Et vérifiant rapidement, j'ai vu des cas similaires à Ottawa. Je n'ai 
cependant pas analysé plus en détail la qualité des éditions pour le projet 
bc2020. Cependant, il ne faut pas oublier qu'il est important d'assurer un bon 
suivi des nouveaux. Souvent ils se concentrent sur les immeubles mais 
produisent des résultats très imprécis. Il est important de les accompagner et 
corriger rapidement. Sinon, les contributeurs plus expérimentés éviterons 
ensuite ces zones avec autant de problèmes à corriger.
Rappellons que depuis le début, ce sont des représentants de MapBox qui ont 
présenté ce projet et créé une certaine confusion sur le rôle de la communauté 
OSM du Canada. Nous avons été très clairs que ce projet n'est pas une priorité 
pour notre communatué. Ils sont revenus à la charge avec la semaine Geoweek, 
mettant encore de l'avant le projet bc2020 et invitant les universités à y 
participer. Je suis en désaccord avec ce mode de fonctionnement des partenaires 
corporatifs qui prennent des décisions au nom de notre communauté et n'assurent 
pas ensuite les responsabilités reliées à de tels projets.
J'ai analysé le travail effectué par les contributeurs OSM dans le cadre de la 
semaine GeoWeek (données du 12 au 20 novembre). Pour le projet bc2020, sept 
projets ont été créés sur le serveur tasks.osmcanada.ca par le contributeur 
Noznoc. Je ne saurais dire s'il est lié à MapBox. Au Canada, 167 contributeurs 
ont édité 82,570 objets (environ 16,500 immeubles, 494 immeubles par personne). 
Parmi eux, 96 nouveaux contributeurs depuis le début de la semaine dernière ont 
édité 38,211 objets (environ 7,640 immeubles, 80 immeubles par personne). Comme 
John l'a souvent souligné, il est important de repérer rapidement les 
problèmes. Sinon les contributeurs expérimentés éviterons ensuite d'éditer ces 
zones, puisqu'il est plus long de corriger ces données tout en conservant 
l'historique que de partir d'une feuille vierge et y ajouter de nouveaux 
immeubles à l'aide du greffon immeubles de JOSM.

A part d'inviter les universités à participer, MapBox n'a assuré aucun suivi au 
cours de la semaine et la validation du travail des nouveaux participants a été 
quasiment nulle si on se fie aux statistiques du serveur de tâches (quelques 
carreaux en vert).
Aussi pour le suivi de tels projets, il est important de bien documenter les 
projets sur le gestionnaire de tâches. Dans les instructions de différents 
projets listés ci-dessous, aucune référence n'est ajoutée. Idéalement, ont 
devrait y retrouver une référence du style #osmcanada-xx (xx=projet). J'ai pu 
néanmoins déterminer dans la base de données des Changesets les statistiques de 
contributions au projet #bc2020 présentées ci-haut.

Projets sur tasks.osmcanada.ca83 Calgary
85 Durham 

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Charles Basenga Kiyanda]

Bonjour Pierre,

Juste quelques précisions car j'ai été impliqué dans une de ces activités. Dans 
le cas de Williams Lake (projet 91), il a été utilisé pour un mapathon d'un 
nouveau groupe (Open Mapping Group McGill). C'est un nouveau groupe, mais qui 
me semble très bien organisé. Il ya eu trois présentations qui, en tout,, ont  
duré  environ 1h15,, avant que les participants se mettent à contribuer. 

Le projet sur le gestionnaire de tâches à été créé par Julia Conzon (sp?) de 
Mapbox qui a donné une des conférences par vidéo. J'assume que c'est 
l'utilisateur noznoc.

Pour ce qui est de cet événement en particulier, c'est vrai que la partie 
validation tarde, mais je crois bien qu'elle se fera. Leur groupe semble très 
bien organisé. Il émane surtout du département de géographie avec un bon 
support de membres du personnel. 

Je n'extrapolerai pas aux autres activités et je commentterai pas sur les 
techniques de Mapbox, mais pour ce qui est de l'activité à McGill liée à 
williams Lake, c'était une activité bien organisée.

Maintenant, il reste à structurer la validation des données. C'est sûr que sans 
l'urgence d'un projet HOT, c'est plus difficile de motiver les gens à continuer 
leur implication.

Charles

On November 20, 2017 8:56:18 PM EST, "Pierre Béland"  wrote:
>John
>Je t'ai informé précédemment que je constatais pour Calgary des
>doublons d'adresse, celle-ci était ajoutée à la fois sur l'immeuble
>principal et le garage. Et vérifiant rapidement, j'ai vu des cas
>similaires à Ottawa. Je n'ai cependant pas analysé plus en détail la
>qualité des éditions pour le projet bc2020. Cependant, il ne faut pas
>oublier qu'il est important d'assurer un bon suivi des nouveaux.
>Souvent ils se concentrent sur les immeubles mais produisent des
>résultats très imprécis. Il est important de les accompagner et
>corriger rapidement. Sinon, les contributeurs plus expérimentés
>éviterons ensuite ces zones avec autant de problèmes à corriger.
>Rappellons que depuis le début, ce sont des représentants de MapBox qui
>ont présenté ce projet et créé une certaine confusion sur le rôle de la
>communauté OSM du Canada. Nous avons été très clairs que ce projet
>n'est pas une priorité pour notre communatué. Ils sont revenus à la
>charge avec la semaine Geoweek, mettant encore de l'avant le projet
>bc2020 et invitant les universités à y participer. Je suis en désaccord
>avec ce mode de fonctionnement des partenaires corporatifs qui prennent
>des décisions au nom de notre communauté et n'assurent pas ensuite les
>responsabilités reliées à de tels projets.
>J'ai analysé le travail effectué par les contributeurs OSM dans le
>cadre de la semaine GeoWeek (données du 12 au 20 novembre). Pour le
>projet bc2020, sept projets ont été créés sur le serveur
>tasks.osmcanada.ca par le contributeur Noznoc. Je ne saurais dire s'il
>est lié à MapBox. Au Canada, 167 contributeurs ont édité 82,570 objets
>(environ 16,500 immeubles, 494 immeubles par personne). Parmi eux, 96
>nouveaux contributeurs depuis le début de la semaine dernière ont édité
>38,211 objets (environ 7,640 immeubles, 80 immeubles par personne).
>Comme John l'a souvent souligné, il est important de repérer rapidement
>les problèmes. Sinon les contributeurs expérimentés éviterons ensuite
>d'éditer ces zones, puisqu'il est plus long de corriger ces données
>tout en conservant l'historique que de partir d'une feuille vierge et y
>ajouter de nouveaux immeubles à l'aide du greffon immeubles de JOSM.
>
>A part d'inviter les universités à participer, MapBox n'a assuré aucun
>suivi au cours de la semaine et la validation du travail des nouveaux
>participants a été quasiment nulle si on se fie aux statistiques du
>serveur de tâches (quelques carreaux en vert).
>Aussi pour le suivi de tels projets, il est important de bien
>documenter les projets sur le gestionnaire de tâches. Dans les
>instructions de différents projets listés ci-dessous, aucune référence
>n'est ajoutée. Idéalement, ont devrait y retrouver une référence du
>style #osmcanada-xx (xx=projet). J'ai pu néanmoins déterminer dans la
>base de données des Changesets les statistiques de contributions au
>projet #bc2020 présentées ci-haut.
>
>Projets sur tasks.osmcanada.ca83 Calgary
>85 Durham Region
>86 Stratford
>87 Trail
>88 Massett
>91 Williams Lake
>92 North Battleford
> 
>Pierre 
> 
>
>Le lundi 20 novembre 2017 17:20:20 HNE, john whelan
> a écrit :  
> 
> ___
>Talk-ca mailing list
>Talk-ca@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-ca
>  >BC2020is not a StatCan project.
>That comment came from Bjenk's old boss.
>I note that Pierre has identified some data quality issues from
>maperthons that appear to be associated with this.
>
>Is anyone organising this or is it just a dream in the air?
>
>In Ottawa we got some high quality mapping out of the initial Stats
>Canada project which is good.
>
>The issue on the low 

Re: [OSM-ja] 歩道のマッピング

[Shu Higashi]

あ、

> ただし、ご指摘を受けてよく考えると
> crossing=zebraを使った場合には歩行者用信号機の有無を明示的に表現できなくなる
> という問題があるので、今後はcrossing_ref=zebraを推奨した方が
> 良さそうに感じています。

これ、道路と横断歩道の交点ノードに歩行者用信号機を置けばすむので
crossing_ref=zebra推奨というより、とりあえず様子見で
どちらも可の方が良さそうですね。混乱させてすみません。
東

> 東
>
> 2017/11/19 tomoya muramoto :
>> 瀧口様
>>
>> crossing_refタグは、必ずしも「柄」を意味するものではなく、いろいろひっくるめた歩道の種類を示しています。
>> zebraもpelicanもどちらも「白縞模様」があります。両者の違いは、信号があるかないかです。
>>
>> 日本においては、crossing_refに適した歩道分類がないと思うので、
>> 東さんの提案通り、(ウェイに付与するのであれば)白縞模様がある場合はcrossing=zebra,
>> 白縞模様がない場合はcrossing=unmarkedでよいのではないでしょうか。
>> (もちろん、ここの議論でcrossing_refを導入して、crossing_ref=zebra/unmarkedを採用する案もあるかと思います。)
>>
>> muramoto
>>
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 歩道のマッピング

[Shu Higashi]

瀧口さん、みなさん

ご指摘ありがとうございます。この件、お返事が遅くなりました。
利用件数でいえば
crossing_ref=zebraは280,549件
https://taginfo.openstreetmap.org/keys/crossing_ref#values
crossing=zebraは325,160件
https://taginfo.openstreetmap.org/keys/crossing#values
と、後者のほうが多いのですが
確かによくよくwiki記事を探してみると
前者の記述はあっても後者の記述は見当たらないので
本来タグ付けの整理が必要な内容なんでしょうね。

元々の古い横断歩道の提案では
https://wiki.openstreetmap.org/wiki/Approved_features/Road_crossings
crossingは横断歩道の種別（歩行者用信号の有無）
crossing_refはその地域での横断歩道の呼称
となっています。
高解像度の衛星画像で横断歩道がウェイで書けるようになったことに
対応してノードとウェイでそれぞれ何を表現するか再定義が
必要なのでしょうけどまだ過渡期で整理しきれていない
というところなのではないかと思います。

現時点での整理としては、日本の白縞模様の横断歩道の表現として
crossing_ref=zebraが正しいがcrossing=zebraもデファクトで
使われているので許容する
ということでいかがでしょうか。

ただし、ご指摘を受けてよく考えると
crossing=zebraを使った場合には歩行者用信号機の有無を明示的に表現できなくなる
という問題があるので、今後はcrossing_ref=zebraを推奨した方が
良さそうに感じています。

東

2017/11/19 tomoya muramoto :
> 瀧口様
>
> crossing_refタグは、必ずしも「柄」を意味するものではなく、いろいろひっくるめた歩道の種類を示しています。
> zebraもpelicanもどちらも「白縞模様」があります。両者の違いは、信号があるかないかです。
>
> 日本においては、crossing_refに適した歩道分類がないと思うので、
> 東さんの提案通り、(ウェイに付与するのであれば)白縞模様がある場合はcrossing=zebra,
> 白縞模様がない場合はcrossing=unmarkedでよいのではないでしょうか。
> (もちろん、ここの議論でcrossing_refを導入して、crossing_ref=zebra/unmarkedを採用する案もあるかと思います。)
>
> muramoto
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Pierre Béland]

John
Je t'ai informé précédemment que je constatais pour Calgary des doublons 
d'adresse, celle-ci était ajoutée à la fois sur l'immeuble principal et le 
garage. Et vérifiant rapidement, j'ai vu des cas similaires à Ottawa. Je n'ai 
cependant pas analysé plus en détail la qualité des éditions pour le projet 
bc2020. Cependant, il ne faut pas oublier qu'il est important d'assurer un bon 
suivi des nouveaux. Souvent ils se concentrent sur les immeubles mais 
produisent des résultats très imprécis. Il est important de les accompagner et 
corriger rapidement. Sinon, les contributeurs plus expérimentés éviterons 
ensuite ces zones avec autant de problèmes à corriger.
Rappellons que depuis le début, ce sont des représentants de MapBox qui ont 
présenté ce projet et créé une certaine confusion sur le rôle de la communauté 
OSM du Canada. Nous avons été très clairs que ce projet n'est pas une priorité 
pour notre communatué. Ils sont revenus à la charge avec la semaine Geoweek, 
mettant encore de l'avant le projet bc2020 et invitant les universités à y 
participer. Je suis en désaccord avec ce mode de fonctionnement des partenaires 
corporatifs qui prennent des décisions au nom de notre communauté et n'assurent 
pas ensuite les responsabilités reliées à de tels projets.
J'ai analysé le travail effectué par les contributeurs OSM dans le cadre de la 
semaine GeoWeek (données du 12 au 20 novembre). Pour le projet bc2020, sept 
projets ont été créés sur le serveur tasks.osmcanada.ca par le contributeur 
Noznoc. Je ne saurais dire s'il est lié à MapBox. Au Canada, 167 contributeurs 
ont édité 82,570 objets (environ 16,500 immeubles, 494 immeubles par personne). 
Parmi eux, 96 nouveaux contributeurs depuis le début de la semaine dernière ont 
édité 38,211 objets (environ 7,640 immeubles, 80 immeubles par personne). Comme 
John l'a souvent souligné, il est important de repérer rapidement les 
problèmes. Sinon les contributeurs expérimentés éviterons ensuite d'éditer ces 
zones, puisqu'il est plus long de corriger ces données tout en conservant 
l'historique que de partir d'une feuille vierge et y ajouter de nouveaux 
immeubles à l'aide du greffon immeubles de JOSM.

A part d'inviter les universités à participer, MapBox n'a assuré aucun suivi au 
cours de la semaine et la validation du travail des nouveaux participants a été 
quasiment nulle si on se fie aux statistiques du serveur de tâches (quelques 
carreaux en vert).
Aussi pour le suivi de tels projets, il est important de bien documenter les 
projets sur le gestionnaire de tâches. Dans les instructions de différents 
projets listés ci-dessous, aucune référence n'est ajoutée. Idéalement, ont 
devrait y retrouver une référence du style #osmcanada-xx (xx=projet). J'ai pu 
néanmoins déterminer dans la base de données des Changesets les statistiques de 
contributions au projet #bc2020 présentées ci-haut.

Projets sur tasks.osmcanada.ca83 Calgary
85 Durham Region
86 Stratford
87 Trail
88 Massett
91 Williams Lake
92 North Battleford
 
Pierre 
 

Le lundi 20 novembre 2017 17:20:20 HNE, john whelan  
a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  >BC2020is not a StatCan project.
That comment came from Bjenk's old boss.
I note that Pierre has identified some data quality issues from maperthons that 
appear to be associated with this.

Is anyone organising this or is it just a dream in the air?

In Ottawa we got some high quality mapping out of the initial Stats Canada 
project which is good.

The issue on the low quality mapping by mappers who will map once then 
disappear is what if anything should be done about the less than ideal mapping 
left behind?
Traditionally its been suggested that is it best corrected but it takes longer 
to correct than to delete and remap.

It doesn't seem to be easy to handle at a local level.  There is too much just 
dropped on one spot at once.
One mapper made a comment to me on this type of mapping in Africa just delete 
this junk.  I have some sympathy with this point of view.

Thoughts if any
Thanks John


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

Re: [Talk-us] Multipolygonizing

[Frederik Ramm]

Gleb,

On 11/21/2017 12:02 AM, Gleb Smirnoff wrote:
> Of course multipolygonizing couple of buildings that touch coastline in
> Monterey was wrong. Sorry, I was in a multipolygonizing rage as I was
> going through the coastline. :)

We have a general (unwritten) convention in OSM and that is "don't force
your taste on other mappers".

When you edit data contributed by others, and you improve it with your
own knowledge or data collected on the ground, then nobody expects any
restraint from you - improve away!

However, in matters of taste - where you are NOT adding information, and
instead just changing the represenation of the data in the database - we
tend to say: It is for you to decide the style in which YOU contribute,
but do not try to overrule others and force your style on them.

(There's another issue that mappers never agree on, and that's whether
when there's a track on the edge of the forest and beyond that, a
meadow, all three should share nodes, or whether room is to be left to
the left and right of the track because "the forest doesn't end in the
middle of the track").

These things are matters of taste, and neither representation is more
correct or contains more information than the other; two stubborn
mappers at loggerheads could potentially re-style an area from one style
to the other and back every week.

Hence: Apply your personal style to new contributions that you make, but
don't go around applying it to contibutions made by others. This sort of
"cleanup" benefits few but your personal sense of orderliness, and your
time is better spent actually improving data instead of just fiddling
with how the same data is represented in the database.

Bye
Frederik

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

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

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Briefly (thanks for the reminder, again, Ian!):

If the reltoolbox plug-in as as powerful as I am beginning to understand it may 
be (I appreciate the introduction, Gleb), and given my agreement that certain 
use cases (especially landuse) benefit greatly from multipolygonized boundaries 
(they do), I actually CAN imagine that the SCCGIS V4 landuse import data (in 
2019 or 2020) could become multipolygon.  This likely would involve a 
pre-upload translation of polygon data into mulitipolygon using the tool, then 
conflation (which has to be done anyway).  Except, we upload multipolygons as 
we delete existing polygons during the conflation-and-upload phase.

I wanted to offer that bright spot of hope to anybody's lingering beliefs that 
I am "mule-entrenched" in my beliefs that existing polygons are always 
superior.  They are not.  They make updates harder, but I think I can get over 
that, as I can be convinced that "once done, the time investment is worth it" 
for the future benefits that multipolygons bring.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[André Pirard]

On 2017-11-21 00:08, marc marc wrote:
> Hello,
>
> Le 20. 11. 17 à 23:49, Ubipo . a écrit :
>
>> I don't know of any library that does all that :(
> https://github.com/googlei18n/libphonenumber/
> I never use it but it look like fine.
>
> Regards,
> Marc
That's what the JOSM suggestion
 speaks about.

Cheers

André.



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

Re: [Talk-us] Talk-us Digest, Vol 120, Issue 17

[OSM Volunteer stevea]

This thread is tedious, but I will soldier on.

Gleb Smirnoff  writes:
> Looks like the acception of multipolygons here is not as bad as I initially
> read in this email thread. So, we agree that at some level they are easier
> to maintain that shared nodes. Do we?

I cannot offer you an absolute Yes or No here:  it depends.  Sometimes yes, as 
in the many excellent use cases that Kevin lists as examples (and more!), often 
or usually No when the data are "curated" or part of an import which do not 
already use "shared ways" as OSM might were it to be as efficient as that 
technique allows.  Again, I believe it important to say that one or the other 
might be "more correct" than the other given some particular circumstances, 
however it would be kind to say that neither is fully wrong, they are simply 
different styles of entering data.  One is more efficient, and allows those 
efficiencies to propagate forward into a future where editing things "around 
them" is easier (due to not needing to replicate a large number of shared 
nodes).  Another is simpler (to edit, to understand by novice editors, to 
improve with newer data as part of an import or curated data...) and while 
simple might take up more space in the planet.osm file, there are 
sometimes-good reasons where "simpler is better."  However, "simpler is better" 
is not always true, and shouldn't "win" by default.  OK, I have beaten that 
point to death by now.

> Of course multipolygonizing couple of buildings that touch coastline in
> Monterey was wrong. Sorry, I was in a multipolygonizing rage as I was
> going through the coastline. :)

Apology accepted!

> But the rest of the coastline? The nodes can be shared by any of:
> 1) coastline, 2) beach 3) county & state borders 4) marine preserve.
> And there are ten's of thousands of nodes, because this is a natural
> crazy curved line. This is the most clear example of where multipolygons
> are way easier to draw and maintain than running multiple lines through
> the same set of nodes!
> 
> O> ... it is the process of CONVERTING existing polygons to multipolygons on 
> a widespread basis where it seems there is no good reason for this to occur 
> (and indeed even frustrates import updates).  This is what we are asking you 
> not to do (so much of).
> 
> Well, OSM started in 2006 and support for advanced multipolygons appeared
> in 2011 (correct me if I am wrong). So, at time they came in there were
> already fairly enough data in the database. Should we treat OSM as "write
> only" database? E.g. we only add data, but don't improve already entered?
> The advanced multipolygons appeared because there was a demand for them,
> so why not use them for existing data, if resulting product becomes better?

Improving existing data, especially when they are outdated or just plain wrong, 
is one of the most important things OSM can do.  (We all can agree to that).

> Now, for the import updates. Here I am starting to understand the strong
> pushback against my edits. Import updates is something I never heard
> about! Please tell me more about that. Because in all other places that
> I have edited (Russia, Ukraine, Georgia) imports were treated as something
> that comes in once, and then is adopted into OSM. Do I understand you
> correct that here you got recurring imports, where the import script needs
> to find the object it created previously and edit it? Shoudn't this object
> be protected then? At least a tag note="DO NOT EDIT ME"?

Imports are seldom, if ever, "a script."  They are nearly always carefully 
human-curated data carefully pulled into OSM with a strict, vetted process 
which includes a good deal of Quality Assurance and manual, human oversight.  
THEN, as these data age and likely become outdated, they must be (well, should 
be, by responsible importers) updated in OSM.  If in-between those two phases 
of OSM having "excellent but becoming outdated" data, polygons become 
multipolygons, but the updated data are NOT multipolygons, this greatly 
frustrates the "update the imported data" process.  It doesn't make it 
impossible, it makes it harder, as the process must be refined to include it, 
and the multipolygonization which might have occurred doesn't always have a 
"clean and easy" way to describe it that makes mechanical editing (even humans 
following a list of instructions) easy to complete.  It may be that the 
ultimate winning strategy is, as Kevin says in a recent post to this thread, to 
"convert to multipolygon where correct to do so, the imported data not being 
multipolygon be damned."  I take a deep breath as I do so, but I tend to agree.

> O> > A longer version (I'll try). I assume we all agree that overlapping
> O> > or not reaching polygons where there is adjacency on the ground is
> O> > wrong.
> O> 
> O> "Not-reaching," meaning they create small gaps or "gores," yes, those 
> polygons are technically wrong.  Polygons with overlapping ways, even where 
> 

Re: [OSM-ja] 歩道のマッピング

[Shu Higashi]

muramotoさん

おお、勘違いしていました。
私も横断歩道は
highway=footway
footway=crossing
で描いています。失礼しました。
wikiは後ほど修正しておきます。
東

2017/11/20 Taro Matsuzawa :
> 松澤です。
>
> 東さんの
>  > ただ、私はhighway=crossingで横断歩道のウェイを既にかなり
>  > 描いているので、その描き方も可としてほしいです。
>  > （その前提でソフトウェアも動いていたりする）
> これってたぶん僕が書いてるプログラムを指してると思うのですが、
> highway=crossingの処理は特に書いてなくて、
> highway=footway, footway=crossingでOKのはずです。
>
> たぶん、Nodeに対するものとWayに対するものが
> 東さんのコメントでごっちゃになってないかな？
>
> On 2017/11/20 7:02, tomoya muramoto wrote:
>>
>> はい。そういう整理もあって良いと思います。
>> ぜひご提案ください。
>>
>> では後ほど段階的に詳細化する案をwikiに書きます。
>>
>> ただ、私はhighway=crossingで横断歩道のウェイを既にかなり
>> 描いているので、その描き方も可としてほしいです。
>> （その前提でソフトウェアも動いていたりする）
>>
>> highway=crossingはノードに、footway=crossingはウェイにつける、と住み分け
>> られていることがtaginfo.jp では見て取れます。
>> 　footway=crossing : ノード36件、ウェイ24 892件
>> 　highway=crossing : ノード74 133件、ウェイ25件
>> http://taginfo.openstreetmap.jp/tags/footway=crossing
>> http://taginfo.openstreetmap.jp/tags/highway=crossing
>>
>> デファクトが正しいとは言いませんが、highway=crossingをウェイに適用するメ
>> リットを示していただけませんでしょうか。
>>
>> muramoto
>>
>>
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>>
>
>
> --
> Georepublic Japan Ltd.
> Kobe office:
> c/o CommunityLink
> 5-3-1 Kumoidori, Chuo Ward
> Kobe 651-0096
> Tokyo office:
> SENQ Kasumigaseki, Nittochi Bld.2F
> 1-4-1, Kasumigaseki, Chiyoda-ku
> Tokyo 100-0013
>
> Taro Matsuzawa
> Senior Developer
>
> eMail: t...@georepublic.co.jp
> Web: https://georepublic.info
>
> Tel: +81 (03) 6268 8551
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-us] Multipolygonizing

[Kevin Kenny]

On Mon, Nov 20, 2017 at 6:15 PM, OSM Volunteer stevea
 wrote:
> Please, ENTER data using shared ways where it makes sense to do so.  Nobody 
> is saying "don't do that."  ALSO, please be aware that existing 
> NON-multipolygon data (especially imports and other "curated" data) may very 
> well suffer from the process of being "multipolygonized."  There is a balance 
> to be struck, and I would be very disheartened to see our map become "dumbed 
> down" by data which should be multipolygon somehow become twisted into not.

The cases where I have intentionally converted curated, imported data
to shared ways have all been in imports that I curate myself. I wind
up treating the result as being no different as any other imported
object that's subsequently been modified by a local mapper. If a
reimport discovers that the last user to touch the object wasn't the
import user ID, it flags the upstream data for manual conflation, and
does nothing. Even when it does find that it was the last modifier of
the object, the most it does is to prime JOSM with the proposed change
and let me confirm and commit. The largest data set that I work with
has a couple of thousand polygons. I've done two reimports, each of
which have changed a couple of dozen. Of those, a handful, few enough
to count on fingers, have been subsequently modified by local mappers.
While the initial import ran over a couple of months, an annual
reimport takes me maybe a couple of evenings.

Yes, I did hear a sentiment calling for "dumbing down" the map - and
it wasn't so much you specifically, as that the early returns appeared
to be shaping up into yet another Europe-North America divide. I know
that your position is considerably more subtle; we've discussed this
one fairly extensively already. I just really want to nip the idea in
the bud that simplicity is preferable to correctness.

I'm also fairly cross, because I've discovered in the last week that
two large multipolygon relations that I had spent hours on setting up
had been dismembered. Since they were born in an import (however much
manual editing and conflation was done), I'm not comfortable with
restoring the data, even though significant information has been lost
by the manual changes. In both cases, the topology was damaged by the
Potlatch user, who then 'repaired' things by moving tagging that had
been on the relation to some, but not all, of the outer ways of the
modified object. These were two different users. I suppose this
reinforces both the case that multipolygons should be used only as a
last resort and that imports damage the community, but I'm sad to see
regions of the map lose tagging that had previously been informative,
and begin to feel that my hands are tied from repairing them.

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

Re: [Talk-us] Multipolygonizing

[Ian Dees]

Hi everybody!

Please remember to stay on topic and friendly. This thread seems to be
drifting off into a discussion about the merits of OSM editors.

Also remember that long replies tend to result in people talking past one
another. Short, sweet, and to the point helps a conversation stay on topic.

-Ian
Your friendly talk-us moderator

On Mon, Nov 20, 2017 at 5:24 PM, Andy Townsend  wrote:

> On 20/11/2017 19:36, Gleb Smirnoff wrote:
>
>> Come on, JOSM itself is difficult, but everyone
>> who groked JOSM, never returns to Potlach.
>>
>
> Untrue.  Each of the OSM editors has strengths and weaknesses - it's
> simply a case of finding the best tool for the job.  In some cases that
> might be JOSM; in some cases it might be something completely different
> (StreetComplete?).  JOSM isn't the best at everything - it has a user
> interface out of the fifth circle of hell and seems intent on dragging the
> user straight back there.  It fails with some stuff that is "basic" to e.g.
> Potlatch (mapping with waypoints recorded with information in them as you
> go for example).  See questions such as https://help.openstreetmap.org
> /questions/7675/josm-is-it-possible-to-convert-an-individual
> -waypoint-in-a-gpx-file-to-a-node for a bit more discussion on that.
>
> Best Regards,
> Andy
>
>
> ___
> 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: [Talk-us] Multipolygonizing

[Andy Townsend]

On 20/11/2017 19:36, Gleb Smirnoff wrote:

Come on, JOSM itself is difficult, but everyone
who groked JOSM, never returns to Potlach.


Untrue.  Each of the OSM editors has strengths and weaknesses - it's 
simply a case of finding the best tool for the job.  In some cases that 
might be JOSM; in some cases it might be something completely different 
(StreetComplete?).  JOSM isn't the best at everything - it has a user 
interface out of the fifth circle of hell and seems intent on dragging 
the user straight back there.  It fails with some stuff that is "basic" 
to e.g. Potlatch (mapping with waypoints recorded with information in 
them as you go for example).  See questions such as 
https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node 
for a bit more discussion on that.


Best Regards,
Andy


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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

[François Lacombe]

Bonsoir à tous

Le 20 novembre 2017 à 18:11, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Pour la précision, FVig n’a contribué que sur le Pays de Brest (87
> communes sur 283 avant loi Notre), soit le quart NO du département.
>

Pour la double précision, il s'agit du SIGiste de Brest Métropole Océane
avec qui j'avais pu discuter lorsque j'étais dans la région.

Sur le reste, mon désaccord persiste pour les raisons évoquées.
On devrait d'ailleurs migrer ref:mhs en ref:FR:MHS, pour éviter que nos
monuments historiques soient pris pour des hôpitaux militaires américains
Je suis déjà parti en courant ;)


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

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Kevin and others:  please do not misunderstand me.  There ARE times when shared 
ways between multipolygons is an elegant and THE correct solution, as you, I 
and many others have found to be true and edited into existence many times.  By 
no means do I advocate that where such beauty has been completed that it be 
torn apart and reverted to simple polygons, that would be a giant step 
backwards.  These solutions are NOT "too complicated," and it is a 
misunderstanding of what I have been saying in this thread to think so.

Your statement that "mechanical edits (often by the JOSM tool reltoolbox) 
running roughshod over carefully curated data" strikes at the bullseye of what 
I wish to convey.  Such trampling really makes updating imported (curated) data 
quite difficult, and OSM really DOES want to encourage the updating of imported 
data.  I AM saying:  please BE CAREFUL multipolygonizing polygons, especially 
where tagging or changeset data might indicate they are part of an import or a 
curated set of data.

It may be that as other geodata, especially those which align well with the 
idea that "shared ways are a good idea in these data," become better aligned 
with OSM's multipolygon data structure, this situation greatly improves.  Now, 
there is some alignment, though it is not perfect; for example, shapefile data 
imported into JOSM are either "OK after import" or "come close enough to easily 
fix" (in my opinion).  But concomitant with this is that OSM editors — 
software, novices, intermediates and experts alike — not be afraid of or 
intimidated by relations and/or multipolygons (and editing them).  While our 
"primitive types" of nodes and ways are relatively easy to learn, relations are 
not, but we MUST prioritize it as an important task that even beginning users 
better familiarize themselves and gain comfort with these more complex types of 
data — early, and often.

Please, ENTER data using shared ways where it makes sense to do so.  Nobody is 
saying "don't do that."  ALSO, please be aware that existing NON-multipolygon 
data (especially imports and other "curated" data) may very well suffer from 
the process of being "multipolygonized."  There is a balance to be struck, and 
I would be very disheartened to see our map become "dumbed down" by data which 
should be multipolygon somehow become twisted into not.

SteveA
California

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

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

  Kevin,

On Mon, Nov 20, 2017 at 04:29:56PM -0500, Kevin Kenny wrote:
K> (3) Ease of editing (for better-informed or better-tooled users). At
K> least for me, working in JOSM, I find updating a mesh of multipolygons
K> with shared ways to be fairly straightforward. Split the ways at any
K> new corners, draw any new ways, update the touching regions, delete
K> any obsolete ways. Sure, it's a different workflow than the one for
K> simple polygons, but for that workflow, I find myself retracing over
K> long sets of points, or else splitting, duplicating, reversing and
K> rejoining ways. The duplicated ways are difficult to work with, since
K> they share all the points, and I have to puzzle over some pretty
K> subtle things to understand which copy I'm working with. By contrast,
K> the split and joined ways in a shared-ways structure always have
K> distinct geometry.

Thanks for this paragraph! This was text that was right on my tongue,
but I failed to wordsmith it properly.

-- 
Gleb Smirnoff

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

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

On Mon, Nov 20, 2017 at 02:13:44PM -0800, OSM Volunteer stevea wrote:
O> Plug-ins that offer "power tools" beyond that?  Well, caveat usor.

Note that a large part of current JOSM base functionality before was
in plugins. So, doesn't make sense to diminish some tool because it
isn't in base. Whether some code goes into JOSM or stays as plugin is
driven by two things: 1) number of plugin users 2) willingness of plugin
author to yield his code to JOSM repo, meaning disown his code. And
for many people that also means lose commit access to their code.

-- 
Gleb Smirnoff

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

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[marc marc]

Hello,

Le 20. 11. 17 à 23:49, Ubipo . a écrit :

> I don't know of any library that does all that :(

https://github.com/googlei18n/libphonenumber/
I never use it but it look like fine.

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

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[Ubipo .]

Hey all,

Haha thanks for noticing that rookie mistake Wouter, better now than when I
implement it I guess...
I added some automated tests to check for basic errors like that one to the
repo on GitHub.

Regarding that JOSM thread,
It would be awesome if JOSM had a build-in validator/normalizer/formatter.
Although it could prove difficult if you also want to format the area code
and subscriber number.
Just look all the hoops I had to jump through to get Belgian numbers
working.
I don't know of any library that does all that :(

Anyway, if anybody knows how to PUT a task status on maproulette, do let me
know.

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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[osm . sanspourriel]

Il y a aussi les remarques faites à oc-escorpion : https://www.openstreetmap.org/changeset/51312940

Que a répondu dans une langue que je ne parle pas (je comprends qu'il voulait que le nom en occitan soit visible de tous) mais qui a cessé de contribuer sous ce pseudo.

D'où l'impression de l'avoir dit depuis longtemps.

 

Jean-Yvon

 
 

Gesendet: Freitag, 17. November 2017 um 08:21 Uhr
Von: "Christian Quest - cqu...@openstreetmap.fr" 
An: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales



Si je comprends bien:

- ça fait des mois qu'on discute des contributions de cet utilisateur

- il n'y a eu que 2 changeset commentés il y a quelques jours seulement

- il y a eu plein de revert de faits

 

autre chose ? Des échanges de messages directs ?

 

C'est quand même light, non ?
 

 


 
Le 17 novembre 2017 à 04:42, Francois Gouget  a écrit :

On Thu, 16 Nov 2017, marc marc wrote:
[...]
> Du coup je comprend pas la suite de ton message.
> D'un côté tu as l'air de dire qu'on aurait du faire la procédure
> DWG + tôt (je partage ton avis), de l'autre tu as l'air de dire
> que la première étape (communiquer) est facultative.

J'ai l'impression que cet utilisateur a été largement prévenu, même si
ce n'est peut-être pas de la façon prévue par la procédure officielle.
Avec en plus le flou qui reigne on obtient cette position contradictoire
au premier abord.


> Ajouter des outils pour détecter ou rapporter ce genre de problème
> ne sert à rien si lorsqu'il est détecté, personne ne veux
> lancer la procédure nécessaire pendant des mois...

Problème de dilution des responsabilités ?

Si je comprend bien personne n'est chargé de s'occuper de ces cas là et
donc tout le monde espère que quelqu'un d'autre va s'y coller (ce qui
est bien compréhensible). Désigner à l'avance une personne à contacter
qui va coordonner / gérer ces cas pourrait faire partie des
'améliorations' dont je supputais l'existence.


--
Francois Gouget               http://fgouget.free.fr/
                  A black hole is just God dividing by zero.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
 




--

Christian Quest - OpenStreetMap France


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





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

[Talk-ca] Mapping buildings in Canada by 2020

[john whelan]

>BC2020 *is not a StatCan project*.

That comment came from Bjenk's old boss.

I note that Pierre has identified some data quality issues from maperthons
that appear to be associated with this.

Is anyone organising this or is it just a dream in the air?

In Ottawa we got some high quality mapping out of the initial Stats Canada
project which is good.

The issue on the low quality mapping by mappers who will map once then
disappear is what if anything should be done about the less than ideal
mapping left behind?

Traditionally its been suggested that is it best corrected but it takes
longer to correct than to delete and remap.

It doesn't seem to be easy to handle at a local level.  There is too much
just dropped on one spot at once.

One mapper made a comment to me on this type of mapping in Africa just
delete this junk.  I have some sympathy with this point of view.

Thoughts if any

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

[Talk-cz] Spolupráce/Koordinace - update regionu Dolní Morava, Kralický sněžník

[ludek.kuehr]

Ahoj!

Připravujeme outdoorový portál na platformě OUTDOORACTIVE v regionu Dolní
Morava. Otdooractive používá OSM a patří mezi OSM Contributors. Chtěl bych
naše práce koordinovat s někým, kdo má region na starost J nebo k němu má
blízko.

 

Byli jsme na Dolní Moravě týden v září a týmy procházely a mapovaly v
regionu věci, které nás z hlediska portálu zajímají. 

 

Víc o Outdooractive najdete na
https://corporate.outdooractive.com/en/platform/ 

 

Kontakt: Luděk Kühr, Alpdest CEE s.r.o. / Brno / 60588 /
ludek.ku...@alpdest.com   

 

Luděk

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

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Thank you, Kevin for your thoughtful and rather complete reply!

Mark Wagner  wrote:
> Of course, this only works for ordinary relations.  If the way you
> clicked on is shared by two or more relations, you need to go
> through the far more complicated method of playing with the
> relation-editor dialog.

It is no secret that using either iD or Potlatch for relation editing is 
difficult and error-prone, nigh unto impossible for novice editors to either 
understand or perform easily.  By contrast, while it does take some practice to 
learn, I find JOSM's relation editor to be a straightforward method to edit OSM 
relations.  In short, the "four pane dialog" (not strictly correct, but it 
pedagogically suffices) consists of "key-value pairs on top, (left and right); 
member elements and selections on bottom (left and right)."  Along with the 
buttons to the left of and between the bottom two panes (sort, reverse, select, 
move, ...), you have all you need to edit relations.  This is a modeless (not 
modal) dialog, meaning that while the relation editing window is open, 
selections (e.g. click, drag a selection box...) and operations (e.g. split or 
join...) can/should be performed on underlying data in the geography editing 
window.  Taken together, these are the seeds of learning how to effectively 
edit relations in JOSM.

Plug-ins that offer "power tools" beyond that?  Well, caveat usor.

I wholeheartedly agree with much said in this thread:  both polygons and 
multipolygons are perfectly valid data structures to use in cases where 
choosing one or the other is a matter of taste, preference, use-case, or all 
three.  (Some uses absolutely require multipolygons, and that is that, other 
uses offer a choice of polygons OR multipolygons, where one or the other are 
equally correct).  Notwithstanding JOSM's current paradigm noted above, our 
tools have a ways to go before they present simple methods to edit relations 
(type multipolygon or others) so that all and sundry are comfortable editing 
them.  OSM gets better at this, though it is taking some time to get there.

I believe a most important result from this thread is that there are many use 
cases where either polygons OR multipolygons are correct.  Really, we are not 
very far apart from rather fully agreeing with one another.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] What would make MapRoulette better?

[Pierre Béland]

For JOSM

See this JOSM ticket that address transfer of HOT TM tags 
https://josm.openstreetmap.de/ticket/10758and this HOT TM ticket 
https://github.com/hotosm/osm-tasking-manager2/issues/703
 
Pierre 
 

Le lundi 20 novembre 2017 16:49:39 HNE, Bryan Housel 
 a écrit :  
 
 Hey Martijn, it’s currently possible to send comments and hashtags to iD (they 
can be sent as two different parameters, or just embed the hashtags in the 
comments like the task managers currently do).  It’s not possible to set other 
changeset tags, but it is something I could add if there is a good use case for 
it.

Thanks, Bryan



> On Nov 20, 2017, at 4:44 PM, Martijn van Exel  wrote:
> 
> Hi Pierre,
> 
> That is a good idea and there are already some ‘hashtags’ that MapRoulette 
> sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
> something that could be improved upon. Perhaps with changeset tags (is that 
> what you are suggesting?)
> 
> Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
> remote control / the querystring?
> 
> Martijn
> 
> --  
> Martijn van Exel
> 
> On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
>> Hi Martijn
>> We see an increase of coordinatead actions via QA and TM tools. But this is 
>> not systematically  
>> documented on the Changeset metadata. For QA tools, sometimes we see in the 
>> comments  
>> reference to MapRoulette or other tools.
>> It is possible for these tools to transfer infos to editors such as iD and 
>> JOSM. It would  
>> be good that tags are transferred to the editors to better document the 
>> coordinated actions.  
>> For TM tools, it could be host and project_no / Title. For QA, it could be 
>> host and project.  
>> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds 
>> to a particular  
>> challenge.
>> 
>> Pierre
>> 
>> 
>> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>> 
>> Marc,
>> 
>> Good point and something that has come up often.
>> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
>> owner, to split  
>> up the challenge into regional chunks and label them as such.
>> 
>> The new version will have ‘filter by current map bounds’. I’m not quite sure 
>> how to best  
>> do this yet. One solution would be to filter by challenge ‘centroids’ 
>> (simple), another  
>> would be to consider whatever challenge has at least one task within the 
>> current map bounds  
>> (harder). What would be your idea about this? Others with an opinion?
>> --
>> Martijn van Exel
>> 
>> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
>>> The possibility to work more locally. E.g. there is a project to add
>>> missing roads in Belgium, I would really like to see only the "issues"
>>> within let say 20km of my house (an arbitrary point I can set).
>>> 
>>> m.
>>> 
>>> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
 Hi all,
 
 For those who have used MapRoulette or at least have a good understanding 
 of
 what it does: what would be the *one top thing* for you that would make it
 better?
 
 I am asking because I am working on a new major release.
 --
 Martijn van Exel
 
 ___
 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] What would make MapRoulette better?

[Bryan Housel]

Hey Martijn, it’s currently possible to send comments and hashtags to iD (they 
can be sent as two different parameters, or just embed the hashtags in the 
comments like the task managers currently do).  It’s not possible to set other 
changeset tags, but it is something I could add if there is a good use case for 
it.

Thanks, Bryan



> On Nov 20, 2017, at 4:44 PM, Martijn van Exel  wrote:
> 
> Hi Pierre,
> 
> That is a good idea and there are already some ‘hashtags’ that MapRoulette 
> sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
> something that could be improved upon. Perhaps with changeset tags (is that 
> what you are suggesting?)
> 
> Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
> remote control / the querystring?
> 
> Martijn
> 
> --  
> Martijn van Exel
> 
> On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
>> Hi Martijn
>> We see an increase of coordinatead actions via QA and TM tools. But this is 
>> not systematically  
>> documented on the Changeset metadata. For QA tools, sometimes we see in the 
>> comments  
>> reference to MapRoulette or other tools.
>> It is possible for these tools to transfer infos to editors such as iD and 
>> JOSM. It would  
>> be good that tags are transferred to the editors to better document the 
>> coordinated actions.  
>> For TM tools, it could be host and project_no / Title. For QA, it could be 
>> host and project.  
>> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds 
>> to a particular  
>> challenge.
>> 
>> Pierre
>> 
>> 
>> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>> 
>> Marc,
>> 
>> Good point and something that has come up often.
>> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
>> owner, to split  
>> up the challenge into regional chunks and label them as such.
>> 
>> The new version will have ‘filter by current map bounds’. I’m not quite sure 
>> how to best  
>> do this yet. One solution would be to filter by challenge ‘centroids’ 
>> (simple), another  
>> would be to consider whatever challenge has at least one task within the 
>> current map bounds  
>> (harder). What would be your idea about this? Others with an opinion?
>> --
>> Martijn van Exel
>> 
>> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
>>> The possibility to work more locally. E.g. there is a project to add
>>> missing roads in Belgium, I would really like to see only the "issues"
>>> within let say 20km of my house (an arbitrary point I can set).
>>> 
>>> m.
>>> 
>>> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
 Hi all,
 
 For those who have used MapRoulette or at least have a good understanding 
 of
 what it does: what would be the *one top thing* for you that would make it
 better?
 
 I am asking because I am working on a new major release.
 --
 Martijn van Exel
 
 ___
 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] What would make MapRoulette better?

[Martijn van Exel]

Sorry, something went wrong with my previous email, I think. I’ll try and 
phrase again.

It is a good idea, Pierre, to have various tools use a consistent set of tags 
on changesets. I think that is what you are suggesting? MapRoulette already 
does send some ‘hashtags’ to JOSM. 

Who knows if JOSM and iD support sending changeset tags through remote control 
and query string respectively?

--  
Martijn van Exel

On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
> Hi Martijn
> We see an increase of coordinatead actions via QA and TM tools. But this is 
> not systematically  
> documented on the Changeset metadata. For QA tools, sometimes we see in the 
> comments  
> reference to MapRoulette or other tools.
> It is possible for these tools to transfer infos to editors such as iD and 
> JOSM. It would  
> be good that tags are transferred to the editors to better document the 
> coordinated actions.  
> For TM tools, it could be host and project_no / Title. For QA, it could be 
> host and project.  
> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to 
> a particular  
> challenge.
>  
> Pierre
>  
>  
> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>  
> Marc,
>  
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
> owner, to split  
> up the challenge into regional chunks and label them as such.
>  
> The new version will have ‘filter by current map bounds’. I’m not quite sure 
> how to best  
> do this yet. One solution would be to filter by challenge ‘centroids’ 
> (simple), another  
> would be to consider whatever challenge has at least one task within the 
> current map bounds  
> (harder). What would be your idea about this? Others with an opinion?
> --
> Martijn van Exel
>  
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good understanding 
> > > of
> > > what it does: what would be the *one top thing* for you that would make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > 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] What would make MapRoulette better?

[Pierre Béland]

Martin,
Yes I suggest to add tags to the changeset metadata. On the HOT discussion list 
and the Github Tasking Manager project, you should find discussions about this. 
Yes, it is possible to send these tags with the remote control.
 
Pierre 
 

Le lundi 20 novembre 2017 16:45:02 HNE, Martijn van Exel  a 
écrit :  
 
 Hi Pierre,

That is a good idea and there are already some ‘hashtags’ that MapRoulette 
sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
something that could be improved upon. Perhaps with changeset tags (is that 
what you are suggesting?)

Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
remote control / the querystring?

Martijn

--  
Martijn van Exel

On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
> Hi Martijn
> We see an increase of coordinatead actions via QA and TM tools. But this is 
> not systematically  
> documented on the Changeset metadata. For QA tools, sometimes we see in the 
> comments  
> reference to MapRoulette or other tools.
> It is possible for these tools to transfer infos to editors such as iD and 
> JOSM. It would  
> be good that tags are transferred to the editors to better document the 
> coordinated actions.  
> For TM tools, it could be host and project_no / Title. For QA, it could be 
> host and project.  
> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to 
> a particular  
> challenge.
>  
> Pierre
>  
>  
> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>  
> Marc,
>  
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
> owner, to split  
> up the challenge into regional chunks and label them as such.
>  
> The new version will have ‘filter by current map bounds’. I’m not quite sure 
> how to best  
> do this yet. One solution would be to filter by challenge ‘centroids’ 
> (simple), another  
> would be to consider whatever challenge has at least one task within the 
> current map bounds  
> (harder). What would be your idea about this? Others with an opinion?
> --
> Martijn van Exel
>  
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good understanding 
> > > of
> > > what it does: what would be the *one top thing* for you that would make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > 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] What would make MapRoulette better?

[Martijn van Exel]

Hi Pierre,

That is a good idea and there are already some ‘hashtags’ that MapRoulette 
sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
something that could be improved upon. Perhaps with changeset tags (is that 
what you are suggesting?)

Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
remote control / the querystring?

Martijn

--  
Martijn van Exel

On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
> Hi Martijn
> We see an increase of coordinatead actions via QA and TM tools. But this is 
> not systematically  
> documented on the Changeset metadata. For QA tools, sometimes we see in the 
> comments  
> reference to MapRoulette or other tools.
> It is possible for these tools to transfer infos to editors such as iD and 
> JOSM. It would  
> be good that tags are transferred to the editors to better document the 
> coordinated actions.  
> For TM tools, it could be host and project_no / Title. For QA, it could be 
> host and project.  
> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to 
> a particular  
> challenge.
>  
> Pierre
>  
>  
> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>  
> Marc,
>  
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
> owner, to split  
> up the challenge into regional chunks and label them as such.
>  
> The new version will have ‘filter by current map bounds’. I’m not quite sure 
> how to best  
> do this yet. One solution would be to filter by challenge ‘centroids’ 
> (simple), another  
> would be to consider whatever challenge has at least one task within the 
> current map bounds  
> (harder). What would be your idea about this? Others with an opinion?
> --
> Martijn van Exel
>  
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good understanding 
> > > of
> > > what it does: what would be the *one top thing* for you that would make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > 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: [Talk-it] Mappatura piramidi

[carlo folini]

Ciao,
con earth_pyramid non c'è nessun tag (cercato sia su taginfo che overpass
turbo), quindi eviterei di introdurlo.
Per l'uso di
natural=stone
che ne dite?
Effettivamente questa formazione è abbastanza particolare, quindi potrei
anche fregarmene e mappare senza farmi troppe seghe mentali ;-)

Il giorno 19 novembre 2017 22:16, Volker Schmidt  ha
scritto:

> I would prefer earth_pyramid over hoodoo. According to the English
> Wikipedia they are synonyms: https://en.wikipedia.org/wiki/
> Hoodoo_(geology). The German Wikipedia article "Erdpyramide" is connected
> to the English article "Hoodoo".
>
> 2017-11-19 21:38 GMT+01:00 carlo folini :
>
>> Stavo mappando le "piramidi" di Postalesio
>> http://www.openstreetmap.org/way/541765618
>> che sono delle colonne di terra con un masso a cappello.
>> https://en.wikipedia.org/wiki/Hoodoo_%28geology%29
>>
>> Guardando gli altri esempi vedo che non c'è uno standard:
>> natural=bare_rock
>> 
>>  http://www.openstreetmap.org/way/428924925/history
>> natural=rock http://www.openstreetmap.org/way/42862953
>>
>> Io sarei più dell'idea di mappare con
>> natural=stone
>> http://wiki.openstreetmap.org/wiki/Tag:natural%3Dstone
>> "rock fragment that is not attached to the underlying terrain and
>> arrived in its position by natural means, such as weathering, flooding or
>> glaciation."
>>
>> C'è una proposta di aggiungere il tag
>> rock=hoodoo
>> https://forum.openstreetmap.fr/viewtopic.php?f=2=4980
>> Che però non mi sembra molto standard, sebbene abbia parecchie occorrenze
>> su osm
>> http://overpass-turbo.eu/s/kBX
>>
>> Che ne dite?
>>
>> --
>> Carlo Folini
>> mailto:carlo.fol...@gmail.com
>>
>>
>> 
>>  Mail
>> priva di virus. www.avast.com
>> 
>> <#m_-7816807898163253811_m_-1831668805463939871_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


-- 
Carlo Folini
mailto:carlo.fol...@gmail.com
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Multipolygonizing

[Kevin Kenny]

I'm somewhat relieved to hear Gleb and Frederik injecting a voice
indicating that 'shared ways' separating regions might be an
acceptable approach, because I've adopted it myself. Well, to some
extent, any way.

I'm generally against sharing ways EXCEPT when topology demands it -as
it often does. It's pretty nonsensical to start going to shared ways
just because a building abuts a parking field, for instance.

Still, if two adjacent polygons are the same sort of thing, or
specifically defined to be conterminous, then I certainly want to
share the boundary. By the "same sort of thing," I mean administrative
regions that share a boundary, or different land uses (following our
presumption that a piece of land has only one land use), or different
types of land cover (including water). And 'specifically defined to be
coterminous' includes things like parks that stop at a waterfront.

I would tend to avoid shared ways for things like a wood that stops at
the boundary line of a protected area. The trees don't know where the
boundary is, and the boundary won't move if the adjacent landowner
allows his plot to go back to nature.

There are several reasons for shared ways between topologically adjacent areas.

(1) Data consistency. This is the primary reason. As Gleb points out,
if a shared boundary is a single way, there's no chance that someone
will retrace the boundary of one of the neighbouring regions without
retracing the other, or will enter them inconsistently in the first
place.

(2) Rendering. We've already discovered for boundary=administrative
that representing bordering regions as separate polygons sharing only
nodes rules out using things like dashed-line rendering, because each
boundary will be rendered twice, and there is nothing to ensure that
the dashes will be in the same relative phase; dashed lines tend to
turn into solid lines in such a scheme. That's one of several reasons
that we have tried to keep shared ways on all boundary=administrative
meshes. I foresee in the future (and already confront in my own
rendering) cases where protected areas, or even things like
leisure=park, are rendered similarly and therefore need shared ways to
get a clear display.

(3) Ease of editing (for better-informed or better-tooled users). At
least for me, working in JOSM, I find updating a mesh of multipolygons
with shared ways to be fairly straightforward. Split the ways at any
new corners, draw any new ways, update the touching regions, delete
any obsolete ways. Sure, it's a different workflow than the one for
simple polygons, but for that workflow, I find myself retracing over
long sets of points, or else splitting, duplicating, reversing and
rejoining ways. The duplicated ways are difficult to work with, since
they share all the points, and I have to puzzle over some pretty
subtle things to understand which copy I'm working with. By contrast,
the split and joined ways in a shared-ways structure always have
distinct geometry.

By contrast, the chief argument against multipolygons is that they are
unfriendly to newcomers.  I'll happily concede this point in part.
They certainly demand a somewhat deeper understanding of the data
model, and the newcomer-friendly tools such as Potlatch don't really
do them competently. This argument is stronger that Gleb and Frederik
appear to recognize. Given the difficulty of recruiting mappers, we
surely want to make life as easy as possible for newbies, even if that
comes at some expense in the ease of use for the old hands.

That said, how likely is a newcomer to be editing a complex mesh of
land use or land cover and not mess up the topology, however it's
represented? I suspect that new mappers attempting to adjust these
features will always wind up creating overlaps, gores and broken
multipolygons. (SOME multipolygons are unavoidable because areas have
enclaves or exclaves!) Moreover, part of the newcomer-unfriendliness
comes from the fact that examples of shared ways are sparse, and tend
to be on stable things like administrative regions, the shorelines of
large waterbodies, and similar features that newcomers are
(rightfully) a little afraid to edit in the first place.  Heck, how
many newcomers will even recognize that topology is important?

I may have a somewhat warped view of things. I got into using shared
ways when tidying conflicting imports of various public lands in New
York State, where there were many gores among county and township
lines, shorelines, and the boundaries of various sorts of protected
area. The boundaries are topologically complex, and being constrained
to deal with them by retracing partial ways would be a nightmare.
Shared ways was really the only approach that worked, and from what I
hear, for complex cases, it's still considered acceptable. That's a
relief!

Once I became fluent with the approach of using shared ways, I've come
to use it when, for instance, adding landcover or land use polygons
even in my own neighbourhood. Even there, it 

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

On Mon, Nov 20, 2017 at 11:43:34AM -0800, Mark Wagner wrote:
M> > (I couldn't for the life of  me figure out how to add a way to a
M> > relation!)
M> 
M> Select a way currently part of the relation.  Shift-click on the way
M> you want to add.  Select "Update multipolygon" from the "Tools" menu,
M> or hit Ctrl+Shift+B.  Simple.
M> 
M> Of course, this only works for ordinary relations.  If the way you
M> clicked on is shared by two or more relations, you need to go
M> through the far more complicated method of playing with the
M> relation-editor dialog.

Or use "reltoolbox" plugin, where there is a notion of current  
 
relation, and while you got your relation selected as current,  
 
adding or removing objects to it is clicking "+" or "-" icon on 
 
the sidebar, having object selected. For multipolygons it will also 
 
set "outer" or "inner" role automatically.  

-- 
Gleb Smirnoff

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

Re: [Talk-it] Editor ID e layer di sfondo

[Martin Koppenhoefer]

sent from a phone

> On 19. Nov 2017, at 23:03, Davide Sandona'  wrote:
> 
> Ho un paio di domande riguardo l'editor online ID:
> 1. esiste la possibilità di caricare la cartografia PCN? Secondo la pagina 
> wiki no, ma è vecchia di un paio d'anni... [1]


no, perché è disponibile solo tramite WMS e non consentono il caching delle 
tiles. Il PCN oramai è abbastanza vecchio (e la risoluzione non è altissima), 
la versione più recente è del 2012 (oppure ci sono novità?). Dal PCN possiamo 
usare soltanto le ortofoto, la cartografia no.


Se ti posso suggerire, dai un’occhiata a Josm, che ha molti vantaggi oltre il 
PCN rispetto a iD, per esempio quando ci sono le relazioni (e ci sono 
comunque), è molto più potente, soprattutto vedi meglio cosa succede, perché 
hai più spazio per tag e relazioni rispetto alla sidebar di iD.


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

Re: [OSM-talk] What would make MapRoulette better?

[Yuri Astrakhan]

Martijn, I think this is very similar to what Osmose does in its DB view
(and I think several other tools do in the map view) - they offer a choice
of a "world view" (unfiltered) or a "region views" - where users may choose
what region they are interested in (e.g. a dropdown).

I think it would be better for MR to offer users an automatic preset region
filtering, rather than requiring each challenger author to create regional
sub-challenges.

On Mon, Nov 20, 2017 at 3:48 PM, Martijn van Exel  wrote:

> Marc,
>
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a
> challenge owner, to split up the challenge into regional chunks and label
> them as such.
>
> The new version will have ‘filter by current map bounds’. I’m not quite
> sure how to best do this yet. One solution would be to filter by challenge
> ‘centroids’ (simple), another would be to consider whatever challenge has
> at least one task within the current map bounds (harder). What would be
> your idea about this? Others with an opinion?
> --
> Martijn van Exel
>
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com)
> wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good
> understanding of
> > > what it does: what would be the *one top thing* for you that would
> make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > 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] What would make MapRoulette better?

[Pierre Béland]

Hi Martijn
We see an increase of coordinatead actions via QA and TM tools. But this is not 
systematically documented on the Changeset metadata. For QA tools, sometimes we 
see in the comments reference to MapRoulette or other tools. 
It is possible for these tools to transfer infos to editors such as iD and 
JOSM. It would be good that tags are transferred to the editors to better 
document the coordinated actions. For TM tools, it could be host and project_no 
/ Title. For QA, it could be host and project. 
For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to a 
particular challenge.
 
Pierre 
 

Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel  a 
écrit :  
 
 Marc, 

Good point and something that has come up often.
As Joost mentioned in a reply, the easy solution for this is, as a challenge 
owner, to split up the challenge into regional chunks and label them as such. 

The new version will have ‘filter by current map bounds’. I’m not quite sure 
how to best do this yet. One solution would be to filter by challenge 
‘centroids’ (simple), another would be to consider whatever challenge has at 
least one task within the current map bounds (harder). What would be your idea 
about this? Others with an opinion?
--  
Martijn van Exel

On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> The possibility to work more locally. E.g. there is a project to add
> missing roads in Belgium, I would really like to see only the "issues"
> within let say 20km of my house (an arbitrary point I can set).
>  
> m.
>  
> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > Hi all,
> >
> > For those who have used MapRoulette or at least have a good understanding of
> > what it does: what would be the *one top thing* for you that would make it
> > better?
> >
> > I am asking because I am working on a new major release.
> > --
> > Martijn van Exel
> >
> > ___
> > 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] What would make MapRoulette better?

[Martijn van Exel]

Marc, 

Good point and something that has come up often.
As Joost mentioned in a reply, the easy solution for this is, as a challenge 
owner, to split up the challenge into regional chunks and label them as such. 

The new version will have ‘filter by current map bounds’. I’m not quite sure 
how to best do this yet. One solution would be to filter by challenge 
‘centroids’ (simple), another would be to consider whatever challenge has at 
least one task within the current map bounds (harder). What would be your idea 
about this? Others with an opinion?
--  
Martijn van Exel

On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> The possibility to work more locally. E.g. there is a project to add
> missing roads in Belgium, I would really like to see only the "issues"
> within let say 20km of my house (an arbitrary point I can set).
>  
> m.
>  
> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > Hi all,
> >
> > For those who have used MapRoulette or at least have a good understanding of
> > what it does: what would be the *one top thing* for you that would make it
> > better?
> >
> > I am asking because I am working on a new major release.
> > --
> > Martijn van Exel
> >
> > ___
> > 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-us] Multipolygonizing

[OSM Volunteer stevea]

On Nov 20, 2017, at 11:32 AM, Gleb Smirnoff  wrote:
>  Hi Steve,
> that was a long rant, I enjoyed reading it.

Thank you, but I'd call it "moderate length" for me, I can and do (infamously) 
rant MUCH longer, as many will attest.

> Your retelling of my
> words is way better than my original text, which you could quote.
> I regret that I yet can't produce such a good text in English.
> That's why often for me it is easier to yield rather than argue
> and stand my position.

I did quote (in several place) your original words, so I'm not sure what your 
point is here, apologies for my confusion.

We must use SOME language to communicate, and while this is talk-us, (and the 
USA has no official language, but English IS widely used), we use English.  I 
am multilingual, but as English is my native tongue, I prefer it to Polish, 
Hungarian, French or Spanish, as I wouldn't be anywhere near as fluent.  
Regrets I am unable to converse with you in Russian.  Your English seems quite 
fluent to me, I encourage you to continue the conversation as best you might 
without feeling the need to simply yield because of your language skills, you 
write quite well (believes this user of English).

> TL;DR version of my reply: I'm not going to touch OSM data in USA
> anymore.

I am disappointed you would take so extreme a stance, as I wish to see quality 
edits done by quality editors to increase OSM's quality, and you can and do 
perform such edits.  What many here are asking you to do is to tone down or 
stop with the "multipolygonization" that you do so much of, especially as it 
changes existing and correct data (simple polygons, sometimes as part of an 
import of official data).  Many agree there simply is no need to do this.  
Existing, correct, (sometimes imported) polygons are important to keep updated 
when needed, but this becomes difficult after your multipolygonization process. 
 Especially as it uses a JOSM plug-in which while you are clearly facile at 
using, is not at all widespread in the USA.  The process of multipolygonization 
is understood, especially by more technically advanced and seasoned OSM 
editors, but it is the process of CONVERTING existing polygons to multipolygons 
on a widespread basis where it seems there is no good reason for this to occur 
(and indeed even frustrates import updates).  This is what we are asking you 
not to do (so much of).

Again, I agree that the end-result of your data is technically correct, and 
indeed it makes sense to do this "sharing of ways" in certain use cases (we can 
both cite many examples — I have certainly done this myself in places).  But to 
go to (especially imported) existing data and rework them into much more 
complex structures when their simplicity is both sufficient and correct seems 
not only a waste of your good time and editing skills, it makes it difficult 
for others.

> A longer version (I'll try). I assume we all agree that overlapping
> or not reaching polygons where there is adjacency on the ground is
> wrong.

"Not-reaching," meaning they create small gaps or "gores," yes, those polygons 
are technically wrong.  Polygons with overlapping ways, even where they share 
nodes (and even if they don't share nodes), no, those are not wrong.  You may 
believe that these are "sloppy" or have superfluous data, and you may even 
prefer your multipolygon approach, but what that does is replaces simple and 
correct data with complex and correct data.  I and others here see little point 
in doing that, especially as it frustrates beginners and complicates import 
updates.

> So how can we properly express adjacency?

We know.  We agree.  We simply don't think this is a good idea to go and do 
this on existing data (on a medium- or large-scale, as you and your JOSM plugin 
do) where to do so simply isn't needed, and indeed complicates further data 
editing.

> Yes, advanced multipolygons is a professional tool, and newcomers
> may find it confusing. Moreover, seasoned mappers who have spent
> lot of time may in JOSM, but never encountered them, may also find
> it difficult initially. Replies on this thread confirm that. But,
> please, guys, don't refuse to learn something new, simply because
> it is difficult! C++ is more difficult than Visual Basic, so let's
> call it "terrible"? Come on, JOSM itself is difficult, but everyone
> who groked JOSM, never returns to Potlach.

We are not refusing to learn this.  We agree your method of data entry is 
valid, as we do it (as Frederik so excellently offers us an example) as well, 
WHERE IT IS WARRANTED TO DO SO.  And, THAT IS NOT EVERYWHERE.

> Look at Frederik Ramm's reply on this thread. One of the longest
> term OSM contributors and member of OSMF Board supports multipolygons.
> Doesn't that doubt your conviction? Try it out, before refusing it.

I have entered and edited thousands of OSM multipolygons:  I and many others 
are are not "against them."  What we are asking is that you not 

Re: [OSM-talk] What would make MapRoulette better?

[joost schouppe]

Marc, as task managers for this Belgian task, Ben and I could just as well
split the Challenge up into smaller bits, e.g. by town/village. For more
labour-intensive Challenges, we will probably do that.

I do agree that it would be nice to do such a thing. I wrote this Github
issue with a single Challenge in mind:
https://github.com/maproulette/maproulette2/issues/355

It might be interesting to also do something similar, but where you can see
-all- maproulette Tasks (regardless of the Challenge) in your local area.






2017-11-20 17:58 GMT+01:00 Marc Gemis :

> The possibility to work more locally. E.g. there is a project to add
> missing roads in Belgium, I would really like to see only the "issues"
> within let say 20km of my house (an arbitrary point I can set).
>
> m.
>
> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel  wrote:
> > Hi all,
> >
> > For those who have used MapRoulette or at least have a good
> understanding of
> > what it does: what would be the *one top thing* for you that would make
> it
> > better?
> >
> > I am asking because I am working on a new major release.
> > --
> > Martijn van Exel
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-us] Multipolygonizing

[Joel Holdsworth]

A longer version (I'll try). I assume we all agree that overlapping
or not reaching polygons where there is adjacency on the ground is
wrong. So how can we properly express adjacency? The simple way is
to run two polygons through the same subset of nodes. The advanced
is to separate this subset into a single line, which will now
belong to two multipolygons. I will try to convince you that using
advanced is easier, when it comes to "heavy" objects, like landuse=
or natural=. Imagine someone has mapped a forest, with a good
detail, precisely following its border with a farmland. Now you
want to map this farmland. In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.




I use them for this all the time.

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

Re: [Talk-us] Multipolygonizing

[Mike N]

On 11/20/2017 2:36 PM, Gleb Smirnoff wrote:

In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.


  This is a good example where multipolygons make sense.   I have run 
into this in the past and naturally migrated to a multipolygon instead 
of clicking through hundreds of nodes.


  However for smaller landuse areas such as residential neighborhoods 
or shopping centers, there may be only 4-20 nodes per adjacent polygon. 
 For those cases, I find that multipolygons only increase the load on 
future maintenance and present a major confusion factor for new users.


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

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

  Hi Steve,

that was a long rant, I enjoyed reading it. Your retelling of my
words is way better than my original text, which you could quote.
I regret that I yet can't produce such a good text in English.
That's why often for me it is easier to yield rather than argue
and stand my position.

TL;DR version of my reply: I'm not going to touch OSM data in USA
anymore.

A longer version (I'll try). I assume we all agree that overlapping
or not reaching polygons where there is adjacency on the ground is
wrong. So how can we properly express adjacency? The simple way is
to run two polygons through the same subset of nodes. The advanced
is to separate this subset into a single line, which will now
belong to two multipolygons. I will try to convince you that using
advanced is easier, when it comes to "heavy" objects, like landuse=
or natural=. Imagine someone has mapped a forest, with a good
detail, precisely following its border with a farmland. Now you
want to map this farmland. In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.

Yes, advanced multipolygons is a professional tool, and newcomers
may find it confusing. Moreover, seasoned mappers who have spent
lot of time may in JOSM, but never encountered them, may also find
it difficult initially. Replies on this thread confirm that. But,
please, guys, don't refuse to learn something new, simply because
it is difficult! C++ is more difficult than Visual Basic, so let's
call it "terrible"? Come on, JOSM itself is difficult, but everyone
who groked JOSM, never returns to Potlach.

Look at Frederik Ramm's reply on this thread. One of the longest
term OSM contributors and member of OSMF Board supports multipolygons.
Doesn't that doubt your conviction? Try it out, before refusing it.

P.S. I know that my attempt to convince you would be as fruitless
as if I tried to convince you to use metric units :)

On Mon, Nov 20, 2017 at 09:58:53AM -0800, OSM Volunteer stevea wrote:
O> I very much agree with Douglas and Rihards that glebius' mapping is (around 
here) unusual, "terrible" and difficult to parse, even for experienced mappers 
who have been mapping for most of the history of OSM, like me.  Glebius is 
right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often 
overwriting correct official (county GIS imported) data simply to not "share 
some nodes" or "improve the mess."  He claims that "the consensus in Russia is 
that advanced polygons is the way to go."  Well, not here, I assure both 
Glebuis and the talk-us list of that unequivocally.
O> 
O> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has 
not yet been built into JOSM's base code!) called "reltoolbox."  It promulgates 
what he calls "advanced multipolygons" and in the below-noted changeset 
acknowledges that he believes these "became a world wide consensus," but of 
course, they have not.  Glebius has glibly assumed reltoolbox and its resulting 
data is widespread, when in fact it is not:  neither locally, regionally, nor 
continentally.  He further says the "quality of OSM data in USA is much worse 
than in other countries" when in fact, my small county of Santa Cruz (through a 
wiki-documented process of both importing local government landuse polygons and 
painfully though lovingly improving them over three revisions and many years) 
actually won a Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  
Well, before glebius snarled up a perfectly geometrically valid coastline and 
many of its landuse polygons, amenities, parks, marinas and recreation areas in 
Santa Cruz before I manually reverted a good number of his "fixes."
O> 
O> Glebius may believe he is "saving data" by "reducing overlapping nodes," but 
the added complexity to do this in multipolygons is distinctly confusing to 
many (most) OSM volunteers, especially beginners who find multipolygons 
confusing or intimidating.  I'm not saying glebius' practices or resulting data 
are wrong, but rather that when they overwrite perfectly already-correct data, 
his time is likely better spent on other OSM tasks.  Especially when he rudely 
calls correct and even award-winning data "a mess."
O> 
O> Please, glebius, don't do this here.  Everybody else in our community find 
your submissions to be confusing and difficult to maintain, this practice is 
ANYTHING BUT widespread (here in North America), you are overwriting valid data 
in a way that makes it nearly impossible to update with better data (especially 
when part of import updates) and whatever small cost you believe you are saving 
in either elegance or the amount of data in the map is very much outweighed by 
"simpler is better."  Simple, while 

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[André Pirard]

  
  
On 2017-11-18 13:49, Ubipo . wrote:


  Hey all,




I wanted to let you know about a tool I made called 'BPF'
  - Belgium Phone Formatter.
When provided with OSM login credentials and a list of OSM
  ID's to fix, it scans those 
  objects for 'phone', 'contact:phone', 'fax' and 'contact:fax'
  tags and attempts to normalize them.
  

Hi,

  I reported to JOSM that someone reported that a Frenchman
reported that he found many invalid phone numbers in OSM tags.
The comments  show that JOSM takes it as seriously as usual
(everybody should use JOSM).
You may want to contact them.

Cheers



  

  André.

  



  
If it fails (sees a difficult/unrecognized number), it
  leaves the whole object unchanged.




The tool/script is mainly meant to make this MapRoulette challenge
  a little easier.
But if you find another use for it feel free to download
  and use the python script from https://github.com/Ubipo/BpfOsmTool.


The reason that particular MapRoulette challenge isn't
  fixed already is that:
One: I wanted some other people's input about whether this
  is a good idea.
And two: I'm having some problems with the MapRoulette API:
  Google
Doc




Best,
Ubipo
ubipo.ski...@gmail.com
OSM Profile
  
  
  
  
  ___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be



The 
  

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

Re: [Talk-us] Multipolygonizing

[Mark Wagner]

On Mon, 20 Nov 2017 10:15:01 -0800
Evin Fairchild  wrote:

> (I couldn't for the life of  me figure out how to add a way to a
> relation!)

Select a way currently part of the relation.  Shift-click on the way
you want to add.  Select "Update multipolygon" from the "Tools" menu,
or hit Ctrl+Shift+B.  Simple.

Of course, this only works for ordinary relations.  If the way you
clicked on is shared by two or more relations, you need to go
through the far more complicated method of playing with the
relation-editor dialog.

-- 
Mark

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

Re: [Talk-cz] Jak vznikají chyby v RUIAN

[Jan Macura]

No hej. Myslel jsem, že tohle je jasný...
Otázka zní, jak nám ta informace pomůže. 樂

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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[majka . zem+talk]

Já určitě ne, jsem v práci a nemám šanci se do Prahy dostat. Tak rychlé spojení 
opravdu nemáme.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fungující transformace z Křováka!

[Jan Macura]

2017-11-20 16:30 GMT+01:00 Petr Vejsada :

> Ano, kvůli té změně.
>

Správná odpověď by byla "ne, kvůli té změně", ale ok, rozumím, netřeba to
dál rozvádět.

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

[Talk-cz] Jak vznikají chyby v RUIAN

[Petr Vejsada]

Ahoj,

tak mi konečně došlo jak vznikají ty rozřezané budovy a chyby typu budova místo 
dvora. Ono je to špatně už v té analogové KM. Definiční body jsou zakreslené na 
nádvoří a pak už se to jen zdigitalizuje. Např. 
http://ruian.poloha.net/20/50.07749/14.46369/bk

Rozřezané domy - to samé v bledě modrém - 
https://ruian.poloha.net/20/50.06357/14.54795/kb . Už v KM jsou zakreslené 
definiční body nikdy neexistujících budov :-/

--
Petr

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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[Jachym Cepicky]

kdyz tam bude za komunitu víc lidí, tak je to myslím ok

já v tuhle dobu zítra opravdu nemůžu

jestli tam je prostor na rečnění nevim, ale štěstí přeje připraveným

2-3 lidi?

Petr, Majka, ...?

On Mon, 20 Nov 2017, 17:08 Petr Vejsada,  wrote:

> Ahoj,
>
> Dne Po 20. listopadu 2017 16:31:08, majka napsal(a):
>
> > Jestli jsem našla dobře, tak je to už zítra
>
> Zítra v Dlouhé? No vlastně bych mohl a coby hlavní autor CzechAddress
> (tedy velký vyžírač opendat) by se to asi i hodilo. Mohu také zmínit, že
> proud dat není jen od státní správy k OSM ale i naopak (hlášení budov).
> Tedy myskím, že to generování reklamačních XML bude tak do týdne, nicméně
> data pro státní správu sbíráme už 3 roky. ?
>
> --
> Petr
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[talk-au] NTLIS WMS

[Jubal Harpster]

Hi All,

I was reading the e-mail back and forth with Geoscience Australia 
(https://wiki.openstreetmap.org/wiki/Attribution/Geoscience_Australia) on the 
use its data alongside OpenStreetMap. The final message in the thread implies 
that the CC-BY waiver given for the 250:00 dataset applies to all data released 
by Geoscience Australia under CC-BY, without having to grant a specific waiver 
for reach one.  This would cover the NTLIS WMS service 
(http://wms1.ntlis.nt.gov.au/ilismap?version=1.3.0=GetCapabilities=WMS).
Am I interpreting this correctly?  Or has anyone received a difference response 
from ga.gov.au?

Thanks,
-Jubal
www.openstreetmap.org/user/jharpster




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

Re: [Talk-us] Multipolygonizing

[Andy Townsend]

On 20/11/2017 17:58, OSM Volunteer stevea wrote:

...  Glebius is right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often overwriting correct official (county GIS 
imported) data simply to not "share some nodes" or "improve the mess."  He claims that "the 
consensus in Russia is that advanced polygons is the way to go."  Well, not here, I assure both Glebuis and the 
talk-us list of that unequivocally.


I'm not a local, just an occasional visitor to the area, but have 
certainly had similar conversations with non-local mappers deciding that 
(for example) a car park near me should be composed of 4 separate ways 
each part of 2 or 3 multipolygons.  The thing that's in shortest supply 
in OSM is mappers, and anything that prevents people from contributing 
should be frowned upon.


I'm guessing he won't be reading talk-us but he does read and reply to 
changeset comments, so I'd suggest commenting there on any particular 
changes worth talking about.


Best Regards,

Andy


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

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[marc marc]

Bonsoir,

> contre le fait d'importer des tag ref dans tous les sens :
> - 4 tags ref:xxx:yyy, source:date, source, etc

Juste pour re préciser, j'ai jamais parler de plein de tag sur les objets. 
Source date etc ont leur place sur le changeset.

Pour la ref, SI il y a un usage, cela me semble utile (par exemple pour faire 
remonter les modifs osm vers la source).
Mais d'expérience, cela n'arrive pas, Voila pourquoi je le trouvais inutile. 
Mais quelqu'un d'autre semblait y voir une utilité. Pas convaincu qu'une ref 
effraye un contributeur (mais par contre pas sûr que cette ref reste pertinente 
en cas de correction de localisation).

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

[Talk-es] Accesibilidad: experiencia en Elche

[Jose Luis Infante]

Hola,

en la reunión que tuvimos sobre accesibilidad comenté que conocía una
experiencia que se realizó en Elche, y quedé que la enviaría a la lista
para darla a conocer, y también por si alguien conoce a alguien de los
organizadores, ya que en el momento de la reunión nadie los conocía.

A continuación paso una relación de enlaces con la experiencia de Elche:

http://www.elche.com/micrositios/fondos-europeos/noticias/ubicando-elche-en-el-mapa-de-openstreetmap/

http://www.cap4access.eu/intro.html

http://myaccessible.eu/putting-elche-openstreetmap/

http://myaccessible.eu/elche-spain-colors-in-the-wheelmap/#more-366

http://myaccessible.eu/mapping-miguel-hernandez-university/#more-905

Como se puede apreciar hay varias organizaciones implicadas en el tema,
como Polibienestar , de la Universitat de
València, la Universidad Miguel Hernández, el propio ayuntamiento de
Elche...

A los que os movéis por el ámbito académico, ¿tenéis contacto con esta
gente? Para conocerlos, saber lo que hacen, cómo lo hacen y también para
que nos conozcan.

Un saludo,

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

Re: [Talk-us] Multipolygonizing

[Evin Fairchild]

Yeah, using multipolygons for everything is quite overkill, and it
certainly does overcomplicate things, and not just for new users, but for
experienced users as well. I mean, if it requires some plugin that I've
never heard of in JOSM to easily edit it, then it's too complicated. I
typically prefer using Potlatch 2 to edit OSM because I find JOSM to be
really user-unfriendly, (I couldn't for the life of me figure out how to
add a way to a relation!) so I prefer that things are kept simple as
possible for idiots like me.

-Evin (compdude)

On Nov 20, 2017 9:59 AM, "OSM Volunteer stevea" 
wrote:

> I very much agree with Douglas and Rihards that glebius' mapping is
> (around here) unusual, "terrible" and difficult to parse, even for
> experienced mappers who have been mapping for most of the history of OSM,
> like me.  Glebius is right in my backyard and I've found his coastal
> "restructurings" (e.g. http://www.osm.org/changeset/46756097) to be
> bizarre and unnecessary, often overwriting correct official (county GIS
> imported) data simply to not "share some nodes" or "improve the mess."  He
> claims that "the consensus in Russia is that advanced polygons is the way
> to go."  Well, not here, I assure both Glebuis and the talk-us list of that
> unequivocally.
>
> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has
> not yet been built into JOSM's base code!) called "reltoolbox."  It
> promulgates what he calls "advanced multipolygons" and in the below-noted
> changeset acknowledges that he believes these "became a world wide
> consensus," but of course, they have not.  Glebius has glibly assumed
> reltoolbox and its resulting data is widespread, when in fact it is not:
> neither locally, regionally, nor continentally.  He further says the
> "quality of OSM data in USA is much worse than in other countries" when in
> fact, my small county of Santa Cruz (through a wiki-documented process of
> both importing local government landuse polygons and painfully though
> lovingly improving them over three revisions and many years) actually won a
> Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  Well,
> before glebius snarled up a perfectly geometrically valid coastline and
> many of its landuse polygons, amenities, parks, marinas and recreation
> areas in Santa Cruz before I manually reverted a good number of his "fixes."
>
> Glebius may believe he is "saving data" by "reducing overlapping nodes,"
> but the added complexity to do this in multipolygons is distinctly
> confusing to many (most) OSM volunteers, especially beginners who find
> multipolygons confusing or intimidating.  I'm not saying glebius' practices
> or resulting data are wrong, but rather that when they overwrite perfectly
> already-correct data, his time is likely better spent on other OSM tasks.
> Especially when he rudely calls correct and even award-winning data "a
> mess."
>
> Please, glebius, don't do this here.  Everybody else in our community find
> your submissions to be confusing and difficult to maintain, this practice
> is ANYTHING BUT widespread (here in North America), you are overwriting
> valid data in a way that makes it nearly impossible to update with better
> data (especially when part of import updates) and whatever small cost you
> believe you are saving in either elegance or the amount of data in the map
> is very much outweighed by "simpler is better."  Simple, while it may share
> a few nodes or overlap some ways, isn't wrong, it is far easier to
> understand and maintain, especially for novice mappers, and ESPECIALLY when
> updates to imported data essentially rely on the "simple polygon" paradigm
> which already works so well in our map.
>
> With respect,
> SteveA
> California
>
>
> Douglas Hembry  writes:
> > Greetings everyone,
> > I've just had a short changeset discussion with mapper glebius prompted
> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My
> > understanding is that the map of this stretch of coastline has been
> > restructured to avoid adjacent ways that share nodes. Accordingly, only
> > a single way ever connects any set of nodes, and the single way
> > participates, if necessary, in multiple relations. A result of this is
> > that in a high density area like downtown Monterey Bay many small areas
> > like building footprints or pedestrian areas are defined as distinct
> > multipolygons, with several ways (outers) making up the outline. An
> > example at:
> >
> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> >
> > (look at Hovden Way near the top, or the outline of 700 Cannery Row,
> > further down near Bubba Gump, comprised of seven outer ways)
> >
> > glebius believes that this approach (with the help of the reltoolbox
> > JOSM plugin) is easier and less error-prone than having multiple simple
> > closed ways (eg, a building footprint and an adjacent pedestrian area)
> > 

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[JB]

Le 19/11/2017 à 14:46, Jérôme Villafruela a écrit :

Je pense qu'il faudrait ajouter le tag ref (champ BIEN_REFERENCE) :
Mon avis doit commencer à être minoritaire par ici, mais j'en profite 
pour le rappeler : contre le fait d'importer des tag ref dans tous les 
sens :
 - ça effraie le nouveau contributeur : si un objet a un tag 
natural=tree, il n'hésitera pas à le modifier. Vous ajoutez 4 tags 
ref:xxx:yyy, source:date, source, etc…, il y réfléchira à trois fois 
avant d'y toucher.
 - si vous n'êtes pas capable de faire une repasse sur ces objets sans 
ce tag ref, est-ce que l'import était vraiment justifié ? Qualité, 
nécessité ?

JB.

PS : et pour vous dire, même moi après plusieurs années, j'hésite 
toujours à toucher à ces objets multiréférencés. Ça veut dire qu'une 
passe algorithmique est possible et qu'on aura d'autant plus de facilité 
à me tomber dessus si je fais une boulette ou ce que quelqu'un estime 
être une boulette. (Du genre : « bordel, j'ai bien indiqué que c'était 
un chemin/track lors de l'import, c'est vérifiable dans le fichier 
d'origine, alors pourquoi tu l'as passé en sentier ? »).



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

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

I very much agree with Douglas and Rihards that glebius' mapping is (around 
here) unusual, "terrible" and difficult to parse, even for experienced mappers 
who have been mapping for most of the history of OSM, like me.  Glebius is 
right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often 
overwriting correct official (county GIS imported) data simply to not "share 
some nodes" or "improve the mess."  He claims that "the consensus in Russia is 
that advanced polygons is the way to go."  Well, not here, I assure both 
Glebuis and the talk-us list of that unequivocally.

Glebius uses a JOSM plugin (and it AMAZES him that this functionality has not 
yet been built into JOSM's base code!) called "reltoolbox."  It promulgates 
what he calls "advanced multipolygons" and in the below-noted changeset 
acknowledges that he believes these "became a world wide consensus," but of 
course, they have not.  Glebius has glibly assumed reltoolbox and its resulting 
data is widespread, when in fact it is not:  neither locally, regionally, nor 
continentally.  He further says the "quality of OSM data in USA is much worse 
than in other countries" when in fact, my small county of Santa Cruz (through a 
wiki-documented process of both importing local government landuse polygons and 
painfully though lovingly improving them over three revisions and many years) 
actually won a Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  
Well, before glebius snarled up a perfectly geometrically valid coastline and 
many of its landuse polygons, amenities, parks, marinas and recreation areas in 
Santa Cruz before I manually reverted a good number of his "fixes."

Glebius may believe he is "saving data" by "reducing overlapping nodes," but 
the added complexity to do this in multipolygons is distinctly confusing to 
many (most) OSM volunteers, especially beginners who find multipolygons 
confusing or intimidating.  I'm not saying glebius' practices or resulting data 
are wrong, but rather that when they overwrite perfectly already-correct data, 
his time is likely better spent on other OSM tasks.  Especially when he rudely 
calls correct and even award-winning data "a mess."

Please, glebius, don't do this here.  Everybody else in our community find your 
submissions to be confusing and difficult to maintain, this practice is 
ANYTHING BUT widespread (here in North America), you are overwriting valid data 
in a way that makes it nearly impossible to update with better data (especially 
when part of import updates) and whatever small cost you believe you are saving 
in either elegance or the amount of data in the map is very much outweighed by 
"simpler is better."  Simple, while it may share a few nodes or overlap some 
ways, isn't wrong, it is far easier to understand and maintain, especially for 
novice mappers, and ESPECIALLY when updates to imported data essentially rely 
on the "simple polygon" paradigm which already works so well in our map.

With respect,
SteveA
California


Douglas Hembry  writes:
> Greetings everyone,
> I've just had a short changeset discussion with mapper glebius prompted 
> by changeset 46612750 "Properly multipolygonize Monterey coast line". My 
> understanding is that the map of this stretch of coastline has been 
> restructured to avoid adjacent ways that share nodes. Accordingly, only 
> a single way ever connects any set of nodes, and the single way 
> participates, if necessary, in multiple relations. A result of this is 
> that in a high density area like downtown Monterey Bay many small areas 
> like building footprints or pedestrian areas are defined as distinct 
> multipolygons, with several ways (outers) making up the outline. An 
> example at:
> 
> https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> 
> (look at Hovden Way near the top, or the outline of 700 Cannery Row, 
> further down near Bubba Gump, comprised of seven outer ways)
> 
> glebius believes that this approach (with the help of the reltoolbox 
> JOSM plugin) is easier and less error-prone than having multiple simple 
> closed ways (eg, a building footprint and an adjacent pedestrian area) 
> sharing a set of nodes on their adjacent boundary. . (I hope I'm 
> representing this accurately, glebius will correct me if I'm getting it 
> wrong).
> 
> In my limited experience I've never encountered this before, and at 
> first sight I'm not convinced, particularly when considering future 
> maintenance. I told glebius that I wanted to find out  what the 
> community thought. Is this just one more valid optional way of mapping? 
> To be recommended for adoption if possible? Or to be avoided? Thoughts?

And Rihards  writes
> not an authoritative opinion : it's terrible. mapping contiguous areas
> as multipolygons results in data that is extremely hard to modify (think
> splitting landuse from a 

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

[Christian Rogel]

> 
> Le 20 novembre 2017 à 00:43, Philippe Verdy  > a écrit :
> 
> 
> Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en 
> 2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec 
> comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre qui 
> sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout depuis en 
> ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le 
> ref:FR:INSEE et resté.
> 
> A mettre à jour... en ref:FR:FANTOIR=ref:FR:INSEE+ref:FR:fantoir et supprimer 
> les ref:FR:INSEE et ref:FR:fantoir
>  

Pour la précision, FVig n’a contribué que sur le Pays de Brest (87 communes sur 
283 avant loi Notre), soit le quart NO du département.

Christian R.

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

Re: [OSM-talk] What would make MapRoulette better?

[Marc Gemis]

The possibility to work more locally. E.g. there is a project to add
missing roads in Belgium, I would really like to see only the "issues"
within let say 20km of my house (an arbitrary point I can set).

m.

On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel  wrote:
> Hi all,
>
> For those who have used MapRoulette or at least have a good understanding of
> what it does: what would be the *one top thing* for you that would make it
> better?
>
> I am asking because I am working on a new major release.
> --
> Martijn van Exel
>
> ___
> 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] What would make MapRoulette better?

[Martijn van Exel]

Hi Erwin, 

Can you give an example of what you would like to see and how you would like it 
to work?

-- 
Martijn van Exel

On November 20, 2017 at 6:30:01 AM, Erwin Olario (gov...@gmail.com) wrote:


I wish to see support for OSM tags for tasks.

On Mon, Nov 20, 2017 at 5:02 AM Martijn van Exel  wrote:
Hi all, 

For those who have used MapRoulette or at least have a good understanding of 
what it does: what would be the *one top thing* for you that would make it 
better? 

I am asking because I am working on a new major release. 
-- 
Martijn van Exel
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
--
/Erwin Olario

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

Re: [Talk-cz] Fungující transformace z Křováka!

[majka]

Tohle ale není ani tak posun, jako buď kdysi tak úplně nepřiznaná velká
přestavba (dost časté na vsích), případně i oficiálně nová postavená
budova, a ten pozemek pod je jen zbytek po tom starém baráku. Máme toho
tady po okolí dost. Protože u nových budov vidím takto vydělené pozemky pod
stavbou už jen zřídka.
A dost těchhle budov je teď už jen parkoviště nebo nějaká silnice, a ty
zbytky tam jsou vidět taky. A v RUIAN to zbývá jako budova dost dlouho - u
nás v okolí jsem viděla tyhle "budovy" i 2 až 3 roky poté, co byly opravdu
zbourané - a předpokládám, že oficiálně. Nepředpokládám totiž, že za ně
někdo platil daň z nemovitostí, pokud nemusel.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] [osm-grenoble] Importation des arbres municipaux de Grenoble

[Philippe Verdy]

Le 20 novembre 2017 à 08:12, Christian Quest  a
écrit :

> genus + species ?
>
> Le wiki indique que genus=* est inutile si on renseigne species=*
>
> "The biological classification system is hierarchical. You should use the
> most specific taxon that you know, but there is no need to tag all the
> implicit taxonomic ranks as well. E.g. if you already have tagged a species
> you won't tag the genus as well." (https://wiki.openstreetmap.
> org/wiki/Key:species)
>

C'est à moitié vrai car les reclassifications de genres sont monnaies
courantes et des tas d'espèces conservent leur ancien nom binomial même si
un nouveau nom utilisant le nouveau genre est défini. La taxonomie est un
gros chantier en constante évolution et il y a conflit entre la taxonomie
classique et pluseurs classifications phylogénbétiques qui changent sans
arrêt ou ne sont pas pleinement confirmées (sans compter les cas nombreux
de croisements génétiques au delà des barrières d'espèces conduisant à des
hybrides viables dont il est difficile de déterminer quel est le taxon
parent qud il y en a deux ou plus (rien qu'une cellule animale quelconque
contient plusieurs codes génétiques pour des espèces historiques autrefois
parasitaires et devenues endosymbiotiques et qui ne survivraient plus hors
de leur hôte qui lui non plus ne survivrait pas sans leur "parasite", ce
qui est le cas de tous les animaux).
La classification "phylogénétique" se voudrait purement hiérarchique mais
elle ne cesse d'ajouter des niveaux intermédiaires (et bon nombre ne sont
que des hypothèses car on ne connait pas tout le vivant).
Bref comme il faut bien des points de repère, on a des taxons de genres
clés en classification classique dont on devrait affubler toutes les
espèces, sous-espèces, variétés et cultivars.

Mais concernant les plantations humaines (nos arbres) on a des situations
bien plus complexes aujourd'hui à cause des manipulations génétiques et des
hybrides de plus en plus fréquents (pas toujours viables car inféconds) et
qui n'entrent pas du tout dans le moule de la taxonomie classique. Bref de
nouveaux noms apparaissent qui sont des pseudo-espèces d'un ou plusieurs
genres, et le genre est remplacé par un nom déposé d'hybride. Si on lit un
peu les documents on voit des tonnes de renvois d'un genre à l'autre et des
noms multiples pour une même "espèce" dont le genre est incertain, mais un
nom fait référence en agriculture et n'est pas toujours le taxon
phylogénétique. Il se conserve comme il est même si un nouveau nom
systématique lui a été attribué (qui changera encore quand les recherches
génétiques avanceront...) et qui a déjà changé souvent plusieurs fois en
classification classique.

On ne peut pas demander aux mappeurs de connaitre les détails de ces
recherches: tout le monde utilise les noms visibles dans les offres
commerciales et échanges sylvicoles et si on demande à une municipalité
quels arbres elle a planté, son service technique se fiera aux étiquettes
des vendeurs ou aux indications de leurs cultivateurs de plants...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[Petr Vejsada]

Ahoj,

Dne Po 20. listopadu 2017 16:31:08, majka napsal(a):

> Jestli jsem našla dobře, tak je to už zítra

Zítra v Dlouhé? No vlastně bych mohl a coby hlavní autor CzechAddress (tedy 
velký vyžírač opendat) by se to asi i hodilo. Mohu také zmínit, že proud dat 
není jen od státní správy k OSM ale i naopak (hlášení budov). Tedy myskím, že 
to generování reklamačních XML bude tak do týdne, nicméně data pro státní 
správu sbíráme už 3 roky. ?

--
Petr



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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

[Christian Quest]

Le 20 novembre 2017 à 16:35, Jérôme Amagat  a
écrit :

>
>
> Le 20 novembre 2017 à 00:43, Philippe Verdy  a écrit :
>
>>
>>
>> Le 19 novembre 2017 à 14:32, marc marc  a
>> écrit :
>>
>>> @Vincent @Philippe et donc que proposez-vous concrètement ?
>>> Parce que changer une clef majoritaire qui 'a pas de collision pour une
>>> autre clef qui n'évite pas non plus la collision mais qui ne fait que la
>>> diminuer, c'est un travail de titan pour un gain... très théorique.
>>> Et surtout, faut que quelqu'un s'y mette.
>>
>>
>> Pourtant il faudra bien s'y mettre  car les deux sont très peuplées.
>> Alors modifier +1 ou +7 clés c'est tout de même une modification de
>> masse, autant le faire une fois dans le bon sens...
>> De toute façon des outils sont déjà impactés par l'existence des deux
>> clés, on cassera forcément l'un au détriment de l'autre, mais je ne vois
>> aucun intérêt de garder les deux, ce qui ne rend service à personne !
>>
>
> Pour ref:FR:INSEE, je vient de regarder, il y en a :
> - sur des lieu dit dans le Finistère : + de 1
> - sur des relation associatedStreet autour de Bordeaux : une 60ene
> - une dizaine d'autres
>
> Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en
> 2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec
> comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre
> qui sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout
> depuis en ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le
> ref:FR:INSEE et resté.
>

A mettre à jour... en ref:FR:FANTOIR=ref:FR:INSEE+ref:FR:fantoir et
supprimer les ref:FR:INSEE et ref:FR:fantoir


> Pour Bordeaux, ça représente une toute petite partie des relation
> associatedStreet des différentes communes et je ne vois pas a quoi ça sert.
>

A rien... juste à apporter de la confusion... donc pour moi c'est à
supprimer.



> Après tout ça, il ne reste pas grands chose...
>
> D’après moi, tous les ref:FR:INSEE doivent disparaissent...
>
>
+1 ce sont des résidus d'imports incorrects, ils n'auraient jamais dû
exister.


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Christian Quest]

Et si... il manque le trait d'union.

J'ai envoyé un message à la pref pour qu'ils publient un arrêté
rectificatif... et lien vers la circulaire de la DGCL à ce sujet:
http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf

Le 20 novembre 2017 à 16:17, Jérôme Amagat  a
écrit :

>
>
> Le 19 novembre 2017 à 16:04, Christian Quest  a
> écrit :
>
>> Le 18/11/2017 à 19:20, Jérôme Amagat a écrit :
>>
>>
>>
>> Le 18 novembre 2017 à 18:45, Christian Quest  a
>> écrit :
>>
>>> La règle de toponymie pour les noms officiels est simple...
>>>
>>> Pas d'espace, uniquement des traits d'union, sauf pour l'espace qui suit
>>> l'article en début de nom, exemple:
>>>
>>> La Celle-Saint-Cloud
>>>
>>> La règle est simple... oui mais n'a pas toujours été respecté lors des
>> créations de communes nouvelles ces dernières années. Dans les décision des
>> conseils municipaux et dans les arrêtés préfectoraux il n'y a des espaces
>> donc des communes ont un nom officiel officiel qui ne respectent pas cette
>> règle.
>>
>>
>> Je sais, j'ai même saisit la commission nationale de toponymie sur le
>> sujet et en principe les rectificatifs sont en cours car ces noms sont des
>> erreurs.
>>
>> Autant mettre les noms corrects dans OSM, il me semble que la règle de
>> toponymie est à privilégier pour cohérence.
>> Les préfectures n'ont pas fait leur boulot, l'INSEE non plus, c'est à
>> dire signaler au plus tôt que les noms étaient incorrects et devaient être
>> rectifiés.
>>
>>
>>> Pour Saint-Ours, on a une différence entre le nom sur le noeud place=*
>>> et la relation. Il y a d'autres cas comme cela, je n'y ai pas touché.
>>>
>>> Ceci dit, la regex n'est peut être pas parfaite et améliorable !
>>>
>>>
>> J'ai fait une modification pour Château-Chinon. il y a 2 communes
>> Château-Chinon (ville) et Château-Chinon (Campagne) et il y avait 2 node
>> pour 2 place=village que j'ai fusionné et changé le nom en
>> "Château-Chinon". Les 2 communes ont leur mairie très proche dans la
>> ville avec la mairie de Château-Chinon (Campagne) hors de sa commune. Il me
>> semble logique de faire ce changement : il y a 2 communes mais il n'y a
>> qu'un village (place=village) qui est admin_centre des 2 communes.
>>
>> Christian,
>> Dans le rendu fr il n'y a plus les noms des communes quand il est
>> différent du nom de l'admin_centre pourquoi l'avoir enlevé, je trouvais ça
>> bien.
>>
>>
>>
>> Je ne crois pas que la requête vérifie si le nom est différent. De
>> mémoire, elle ne vérifie que la présence d'un admin_centre. Je peux
>> l'améliorer...
>>
>
> Je pensais que c’était lié aux noms...
> Donc si des noms de communes apparaissaient c'est parce que les communes
> nouvelles n'avait pas encore d'admin_centre dans leur relation et
> maintenant que la plupart l'on ça n’apparaît plus...
> ça doit être beaucoup plus compliqué de comparer les noms des commune et
> admin_centre...
>
> Il y a beaucoup moins de communes nouvelles prévu pour le 1er janvier 2018
> que les années précédentes d’après wikipedia :
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_créées_en_2018
> Il y avait une incitation financière qui n'existe plus il me semble.
> Par contre je vois dans la liste "Val d'Épy", il ne manquerait pas un
> tiret :)
>
>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk] What would make MapRoulette better?

[Ilya Zverev]

Martijn van Exel wrote
> For those who have used MapRoulette or at least have a good understanding of 
> what it does: what would be the *one top thing* for you that would make it 
> better? 

Built-in iD editor, to avoid switching contexts.

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

Re: [OSM-talk-fr] ref:INSEE <> ref:FR:INSEE <> sur quel objet

[Jérôme Amagat]

Le 20 novembre 2017 à 00:43, Philippe Verdy  a écrit :

>
>
> Le 19 novembre 2017 à 14:32, marc marc  a
> écrit :
>
>> @Vincent @Philippe et donc que proposez-vous concrètement ?
>> Parce que changer une clef majoritaire qui 'a pas de collision pour une
>> autre clef qui n'évite pas non plus la collision mais qui ne fait que la
>> diminuer, c'est un travail de titan pour un gain... très théorique.
>> Et surtout, faut que quelqu'un s'y mette.
>
>
> Pourtant il faudra bien s'y mettre  car les deux sont très peuplées. Alors
> modifier +1 ou +7 clés c'est tout de même une modification de
> masse, autant le faire une fois dans le bon sens...
> De toute façon des outils sont déjà impactés par l'existence des deux
> clés, on cassera forcément l'un au détriment de l'autre, mais je ne vois
> aucun intérêt de garder les deux, ce qui ne rend service à personne !
>

Pour ref:FR:INSEE, je vient de regarder, il y en a :
- sur des lieu dit dans le Finistère : + de 1
- sur des relation associatedStreet autour de Bordeaux : une 60ene
- une dizaine d'autres

Pour le Finistere, j'ai l'impression que c'est des imports de lieux dit en
2011 par "FVig" avec comme tag un ref:FR:INSEE et un ref:FR:fantoir. avec
comme valeur, pour ref:FR:fantoir, le fantoir sans les 5 premier chiffre
qui sont le code INSEE. Ce ref:FR:fantoir a été modifié presque partout
depuis en ref:FR:FANTOIR avec la bonne valeur. Problème : pas partout et le
ref:FR:INSEE et resté.
Pour Bordeaux, ça représente une toute petite partie des relation
associatedStreet des différentes communes et je ne vois pas a quoi ça sert.
Après tout ça, il ne reste pas grands chose...

D’après moi, tous les ref:FR:INSEE doivent disparaissent...


> ___
> 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: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[Petr Vejsada]

Dne Po 20. listopadu 2017 14:18:25, Jachym Cepicky napsal(a):

> Hradecká 18, 130 00 Praha 3

Tam? To mám 5 minut pěšky z domova.

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

Re: [Talk-cz] Fungující transformace z Křováka!

[Petr Vejsada]

Dne Po 20. listopadu 2017 15:02:53, Marián Kyral napsal(a):

> Ono někdy totiž KM jaksi neodpovídá ortoforo. Budova ve skutečnosti leží na 
> pozemku trochu jinde, nebo je jinak natočená.

Jednou mi přišlo, že je KM opravdu hodně posunutá vůči ortofotu. Pak jsem to 
prohlédl pozorněji a zjistil jsem, že to tak není. Jednalo se o vysoké budovy a 
ortofoto není brané  vždy kolmo. Půdorys v KM/RUIAN ale přesně seděl na místo 
na zemi a bylo to posunuté ne vůči baráku na zemi, ale vůči střeše.

Petr


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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[majka]

Jestli jsem našla dobře, tak je to už zítra


2017-11-20 15:22 GMT+01:00 Marián Kyral :

> Kdy? Kam?
>
> Marián
>
> -- Původní e-mail --
> Od: Jachym Cepicky 
> Komu: OpenStreetMap Czech Republic 
> Datum: 20. 11. 2017 15:19:28
> Předmět: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme
> data_Zvláštní cena
>
> Dámy a pánové, může někdo z aktivních dorazit?
>
> dik
>
> j
>
> -- Forwarded message -
> From: Lenka Kováčová 
> Date: Mon, 20 Nov 2017, 15:03
> Subject: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena
> To: Jáchym Čepický 
>
>
> Dobrý den Jáchyme,
>
> omlouvám se, že píšu takhle na poslední chvíli, ale ráda bych vám
> oznámila, že hodnotící komise soutěže Společně otevíráme data se rozhodla,
> že komunitě stojící za českými OpenStreetMap udělí zvláštní cenu.
>
> Bylo by proto super, kdybyste na předávání cen přišel osobně, případně
> vyslal zástupce, který diplom převezme.
>
> Najdete si čas?
>
> Díky moc za odpověď.
>
> Hezký den.
>
> Lenka
>
> Lenka Kováčová Koordinátorka Fondu Otakara Motejla
>
> *FOND OTAKARA MOTEJLA*
>
> Hradecká 18, 130 00 Praha 3
>
> t: +420 226 227 705 <226%20227%20705> m: +420 728 863 039
> <728%20863%20039>
>
> e: lenka.kovac...@motejl.cz | w: www.osf.cz
>
> fb: www.facebook.com/nadace.osf | t: @nadaceOSF
>
> Fond Otakara Motejla spravuje Nadace Open Society Fund Praha
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fungující transformace z Křováka!

[Petr Vejsada]

Dne Po 20. listopadu 2017 14:38:56, Jan Macura napsal(a):

> > V budovách TODO přibylo asi 1300 kousků kvůli změně.
> 
> 
> Kvůli změně v RÚIAN? Jakože vznikly (nově se postavily nebo zaměřily)? Nebo
> to myslíš jinak?

Ano, kvůli té změně. Počítá se to tak, že když je alespoň 70% plochy budovy v 
RUIAN pokryto budovou v OSM, tak je to jakoby OK, tedy jakoby ještě v 
toleranci. Pokud je pokryto méně než 70% plochy, tak se bere jako nezmapovaná. 
Tím, že se posunul RUIAN se v některých případech muselo stát, že budova v OSM 
přestala pokrývat alespoň 70% plochy budovy.

Není to nic nečekaného. Spíš jsem se bál, aby to nebyly desetitisíce :-).


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

Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Jérôme Amagat]

Le 19 novembre 2017 à 16:04, Christian Quest  a
écrit :

> Le 18/11/2017 à 19:20, Jérôme Amagat a écrit :
>
>
>
> Le 18 novembre 2017 à 18:45, Christian Quest  a
> écrit :
>
>> La règle de toponymie pour les noms officiels est simple...
>>
>> Pas d'espace, uniquement des traits d'union, sauf pour l'espace qui suit
>> l'article en début de nom, exemple:
>>
>> La Celle-Saint-Cloud
>>
>> La règle est simple... oui mais n'a pas toujours été respecté lors des
> créations de communes nouvelles ces dernières années. Dans les décision des
> conseils municipaux et dans les arrêtés préfectoraux il n'y a des espaces
> donc des communes ont un nom officiel officiel qui ne respectent pas cette
> règle.
>
>
> Je sais, j'ai même saisit la commission nationale de toponymie sur le
> sujet et en principe les rectificatifs sont en cours car ces noms sont des
> erreurs.
>
> Autant mettre les noms corrects dans OSM, il me semble que la règle de
> toponymie est à privilégier pour cohérence.
> Les préfectures n'ont pas fait leur boulot, l'INSEE non plus, c'est à dire
> signaler au plus tôt que les noms étaient incorrects et devaient être
> rectifiés.
>
>
>> Pour Saint-Ours, on a une différence entre le nom sur le noeud place=* et
>> la relation. Il y a d'autres cas comme cela, je n'y ai pas touché.
>>
>> Ceci dit, la regex n'est peut être pas parfaite et améliorable !
>>
>>
> J'ai fait une modification pour Château-Chinon. il y a 2 communes
> Château-Chinon (ville) et Château-Chinon (Campagne) et il y avait 2 node
> pour 2 place=village que j'ai fusionné et changé le nom en
> "Château-Chinon". Les 2 communes ont leur mairie très proche dans la ville
> avec la mairie de Château-Chinon (Campagne) hors de sa commune. Il me
> semble logique de faire ce changement : il y a 2 communes mais il n'y a
> qu'un village (place=village) qui est admin_centre des 2 communes.
>
> Christian,
> Dans le rendu fr il n'y a plus les noms des communes quand il est
> différent du nom de l'admin_centre pourquoi l'avoir enlevé, je trouvais ça
> bien.
>
>
>
> Je ne crois pas que la requête vérifie si le nom est différent. De
> mémoire, elle ne vérifie que la présence d'un admin_centre. Je peux
> l'améliorer...
>

Je pensais que c’était lié aux noms...
Donc si des noms de communes apparaissaient c'est parce que les communes
nouvelles n'avait pas encore d'admin_centre dans leur relation et
maintenant que la plupart l'on ça n’apparaît plus...
ça doit être beaucoup plus compliqué de comparer les noms des commune et
admin_centre...

Il y a beaucoup moins de communes nouvelles prévu pour le 1er janvier 2018
que les années précédentes d’après wikipedia :
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_créées_en_2018
Il y avait une incitation financière qui n'existe plus il me semble.
Par contre je vois dans la liste "Val d'Épy", il ne manquerait pas un tiret
:)


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

Re: [Talk-us] Multipolygonizing

[Frederik Ramm]

Hi,

On 11/19/2017 11:48 PM, Douglas Hembry wrote:
> glebius believes that this approach (with the help of the reltoolbox 
> JOSM plugin) is easier and less error-prone than having multiple simple 
> closed ways (eg, a building footprint and an adjacent pedestrian area) 
> sharing a set of nodes on their adjacent boundary. . (I hope I'm 
> representing this accurately, glebius will correct me if I'm getting it 
> wrong).

He's not entirely wrong; this approach is something we have come to
expect when you have a mesh of areas, like for example county
administrative areas: One begins where the other ends, and allowing each
to have its own "way" connecting the nodes would only increase the
amount of data and complicate editing.

However, when it comes to very small areas, like adjacent buildings or
landuse areas that only share a handful of nodes, introducing a relation
seems an unnecessary complexity.

It is most often mappers with an IT background and an unwillingness, or
even inability, to accept that there can be more than one way to do it
right - they tend to follow the "everything is a multipolygon" approach.
I've occasionally had to forcibly convince them to re-think that
approach because they were essentially turning their home turf into a
creative multipolygon landscape that nobody else dared edit. This is
IMHO the foremost reason against this "multipoligonism" - you're making
things harder to edit for others.

(Another frequent hobby of multipolygon fans is combining several
disjunct areas, say three landuse=farmland areas, into one multipolygon,
because this "saves" space, since landuse=farmland then only needs to be
tagged once not three times. IMHO this is only acceptable if the three
areas have more in common than being farmland; for example if the three
areas together share a local name or so.)

Bye
Frederik

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

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

Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

[Philippe Verdy]

On peut voir que le réseau Mondial Relay consomme à lui tout seul pas mal
de bande passante pour localiser ses points de livraison colis via les
sites marchands.
Idem pour rail.cc.

Il faudrait peut-être voir à les informer qu'on ne peut pas assurer la
qualité de bande passante et de temps de réponse, et qu'ils devraient
utiliser leur propre proxy cache sur pour leur réseau s'ils ne veulent pas
monter leur serveur de tuiles. Ca leur coûterait tellement cher de mettre
un ou deux serveurs Squid pour leur service je ne sais pas si au passage
ils ne participent pas au financement à hauteur du service qu'ils en
attendent, ce qui serait aussi une alternative pour permettre de monter
plus de redondance et de qualité de service pour tous) ?

Je ne sais pas si on peut limiter l'usage par "referer" à une limite
raisonnable. Mais là je pense que les deux sites font trop confiance à
cette ressources gratuite. S'ils ne veulent pas payer d'abonnement chez
Google ou MapBox, un serveur Squid est tout de même le minimum qu'on peut
leur demander (et qui leur assurera aussi un bon temps de réponse, surtout
que leur réseau ne couvre pas tant de territoire que ça, et qu'ils n'ont
pas forcément besoin de zoomer sur toute la planète mais uniquement sur les
points de livraison (ils peuvent désactiver le zoom/panning dynamique et
mettre quelques tuiles basse résolution et des tuiles uniquement dans les
zones couvertes et permettant de distinguer les points de livraison très
locaux).

Pour rail.cc, comme ils demandent à faire des itinéraires, ce sont en
général des grandes distances et les niveaux de zoom élevés ne sont pas
forcément essentiels.

Mais dans les deux cas un proxy cache transparent soulagerait notre service
même si au passage ils participent au financement (matériels à ajouter,
maintenance, frais d'exploitation divers: domaines, certificats, frais de
location et d'accès aux espaces de colocations, factures d'énergie,
sécurité, frais administratifs, participation aux frais de communication,
frais de campagne et de promotion, frais de déplacements...).


Le 19 novembre 2017 à 21:25, Christian Quest  a
écrit :

> J'ai généré des statistiques sur l'usage de 2 serveurs de tuiles maintenus
> par OSM-France depuis le mois de janvier.
>
> Il s'agit d'osm13 et osm25 qui s'occupent principalement des tuiles HOT et
> FR.
>
> Ces stats sont celles du cache de tuiles, qui est hébergé à Lyon par
> Rezopole pour OSM-France (ne pas confondre avec le cache de tuiles pour
> osm.org hébergé aussi par Rezopole à Lyon). L'avantage de Rezopole est
> que ce cache est situé physiquement sur un noeud d'interconnexion, ce qui
> réduit les temps d'accès depuis de nombreux opérateurs et fait aussi que la
> bande passante a un coût nul.
>
> Donc depuis janvier, ce cache a distribué plus de 2,5 milliards de tuiles,
> ce qui représente plus de 38To de données utiles.
> Record le 6 octobre dernier avec 23.8M de tuiles dans la journée !
>
> Les tuiles les plus demandées sont celle du zoom 15 HOT, puis du zoom 18
> FR.
>
> uMap génère 17% des demandes, puis 10.7% pour osm.org (qui permet
> d'afficher le rendu HOT).
>
>
> Le détail est sur http://osm13.openstreetmap.fr/~cquest/report.html
>
> Je vais ajouter une mise à jour si possible quotidienne... et oui, il
> manque quelques jours de stats (disque plein car les logs sont
> volumineux... mais maintenant c'est réglé).
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur de limite admin sur l'ile de la réunion ?

[Jérôme Amagat]

Ces quartiers sont ils seulement des noms de 'lieux dit", des noms utilisés
dans les adresses ou par la population ou alors la mairie s'en sert pour
des conseil de quartier ou autre chose du même genre qui aurait un certain
pouvoir sur leur quartier, avis ou décision?
Si c'est juste des noms de lieu je ne crois pas qu'il faille utiliser des
relation type=boundary boundary=administrative admin_level=10 mais
seulement un place=* sur une relation type multipolygone si les frontières
sont claires ou sur un node. dans ce cas, la "hiérarchie" des quartiers
peut apparaître dans le place=* avec place=suburb plus grand que
place=quarter.
SI il y a des "conseil de quartier", je ne pense pas qu'il faut modifié les
relations qui existent a part peut être enlever les place=* dans les
relation et les mettre sur des node en plus des relations.

Il faudrait peut être prendre contact avec la personne qui a créé ces
relations pour savoir d'où elles arrivent. d’après l'historique des
relations c'est https://www.openstreetmap.org/user/arnaud_mapali qui semble
encore contribuer régulièrement (mais ne doit pas lire cette liste).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[Marián Kyral]

Kdy? Kam?

Marián

-- Původní e-mail --
Od: Jachym Cepicky 
Komu: OpenStreetMap Czech Republic 
Datum: 20. 11. 2017 15:19:28
Předmět: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_
Zvláštní cena
"Dámy a pánové, může někdo z aktivních dorazit?



dik




j



-- Forwarded message -
From: Lenka Kováčová 
Date: Mon, 20 Nov 2017, 15:03
Subject: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena
To: Jáchym Čepický 





Dobrý den Jáchyme,



omlouvám se, že píšu takhle na poslední chvíli, ale ráda bych vám oznámila,
že hodnotící komise soutěže Společně otevíráme data se rozhodla, že komunitě
stojící za českými OpenStreetMap udělí zvláštní cenu.




Bylo by proto super, kdybyste na předávání cen přišel osobně, případně
vyslal zástupce, který diplom převezme. 




Najdete si čas?




Díky moc za odpověď.




Hezký den.




Lenka










Lenka Kováčová Koordinátorka Fondu Otakara Motejla

FOND OTAKARA MOTEJLA


Hradecká 18, 130 00 Praha 3


t: +420 226 227 705 m: +420 728 863 039

e: lenka.kovac...@motejl.cz(mailto:lenka.kovac...@motejl.cz) | w: www.osf.cz
(http://www.osf.cz/)

fb: www.facebook.com/nadace.osf(http://www.facebook.com/nadace.osf) | t: @
nadaceOSF

Fond Otakara Motejla spravuje Nadace Open Society Fund Praha














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

[Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

[Jachym Cepicky]

Dámy a pánové, může někdo z aktivních dorazit?

dik

j

-- Forwarded message -
From: Lenka Kováčová 
Date: Mon, 20 Nov 2017, 15:03
Subject: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena
To: Jáchym Čepický 


Dobrý den Jáchyme,

omlouvám se, že píšu takhle na poslední chvíli, ale ráda bych vám oznámila,
že hodnotící komise soutěže Společně otevíráme data se rozhodla, že
komunitě stojící za českými OpenStreetMap udělí zvláštní cenu.

Bylo by proto super, kdybyste na předávání cen přišel osobně, případně
vyslal zástupce, který diplom převezme.

Najdete si čas?

Díky moc za odpověď.

Hezký den.

Lenka

Lenka Kováčová Koordinátorka Fondu Otakara Motejla

*FOND OTAKARA MOTEJLA*

Hradecká 18, 130 00 Praha 3

t: +420 226 227 705 m: +420 728 863 039

e: lenka.kovac...@motejl.cz | w: www.osf.cz

fb: www.facebook.com/nadace.osf | t: @nadaceOSF

Fond Otakara Motejla spravuje Nadace Open Society Fund Praha
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk] HOT Tech Challenge | Mapping Visualisation Tool

[Mhairi O'Hara]

The Humanitarian OpenStreetMap Team has released a new TECH CHALLENGE!

:: https://www.hotosm.org/job/hot_mapping_visualisation_tool/2017 ::

We are seeking an experienced developer and UX designer to create a
'Mapping Visualisation Tool',

The tool aims to easily automate the creation of downloadable and
embeddable animations, showing the progress of OSM mapping for an area of
interest over a given time period.

Check out the details of the tech challenge and share it with potentially
interested parties. Please note that the application deadline is on the
30th November 2017.

Hope to hear from some of you soon!

Kind regards,

Mhairi

-- 
*Mhairi O'Hara*
Project Manager
mhairi.oh...@hotosm.org
@mataharimhairi

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web 
 | twitter 
 | facebook 
 | donate 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Erreur de limite admin sur l'ile de la réunion ?

[Stéphane Péneau]

Ma "source" locale m'indique que "La Bretagne" fait bien partie du 
quartier Sainte-Clotilde.


Sauf avis contraire, je ferai la modif bientôt.

Stf

Le 17/11/2017 à 22:36, PanierAvide a écrit :

Bonsoir,

Il semblerait, de source locale, que ce soit bien le cas. La résidence 
ici [1] comporte dans son adresse postale la mention du quartier 
Sainte-Clotilde [2]. Ce serait donc vrai pour Le Moufia, et à priori 
le Chaudron. La Bretagne aucune idée.


Cordialement,

Adrien.

[1] http://www.openstreetmap.org/way/147328121
[2] http://www.crous-reunion.fr/logement/cite-louis-timagene-houat/

Le 16/11/2017 à 22:05, Stéphane Péneau a écrit :

Hello !

A priori, la limite administrative du "quartier" Sainte-Clotilde, sur 
l'ile de la Réunion, serait bien plus petite dans Osm qu'elle ne 
l'est en réalité.

http://www.openstreetmap.org/relation/3107586

Selon Wikipédia,  ce quartier en englobe d'autres, comme Le Chaudron, 
La Bretagne, Le Moufia.

https://fr.wikipedia.org/wiki/Sainte-Clotilde_(La_R%C3%A9union)

Est-ce que quelqu'un connait suffisamment la région pour m'éclairer ?

Stf


___
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: [Talk-cz] Fungující transformace z Křováka!

[Marián Kyral]

-- Původní e-mail --
Od: Jan Macura 
Komu: OpenStreetMap Czech Republic 
Datum: 20. 11. 2017 14:40:17
Předmět: Re: [Talk-cz] Fungující transformace z Křováka!
"
Ahoj,




2017-11-20 12:00 GMT+01:00 Petr Vejsada :
"tak hotovy všechny vrstvy (adresy, budovy, ulice, parcely, landuse, budovy-
todo)."

díky za tu práci.


 
"V budovách TODO přibylo asi 1300 kousků kvůli změně."



Kvůli změně v RÚIAN? Jakože vznikly (nově se postavily nebo zaměřily)? Nebo
to myslíš jinak?




"



Petr počítá jak moc se budovy v RUIAN a OSM překrývají a pokud na xx%
souhlasí, tak je budova OK.


Ono někdy totiž KM jaksi neodpovídá ortoforo. Budova ve skutečnosti leží na
pozemku trochu jinde, nebo je jinak natočená.




Zřejmě byly tyto budovy na hraně a po změně se už dostaly za hranu.




Marián___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

[Christian Quest]

goaccess génère un fichier html (ou csv ou json) depuis les logs du serveur
http (nginx dans notre cas). Il n'est pas vraiment prévu pour requêter dans
les logs, restreindre à une période, etc.

L'avantage c'est qu'il ne dépend d'aucun autre outil, il stocke juste dans
des fichiers intermédiaire son état pour juste ajouter des logs au fil de
leur arrivée.

Pour les referer j'ai limité au domaine, histoire de regrouper par site
appelant, plutôt que par page, mais je peux regarder les logs pour avoir
la/les page(s) en question.

Dans les regroupements, j'ai aussi simplifié les URL demandées pour ne
garder que rendu/zoom et pas rendu/zoom/x/y.png


Le 20 novembre 2017 à 14:19, Vincent Frison  a
écrit :

> Effectivement c'est sexy !
>
> Je suis étonné de voir que sur 38 TB seulement 15 viendrait de la France...
>
>
> Le 20 novembre 2017 à 13:38, sly (sylvain letuffe)  a
> écrit :
>
>> Il est très sexy ce goaccess, mais si on gratte, il manque quand même
>> quelques trucs bien utiles (c'est p'tet un truc qui s'active) :
>>
>> Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller
>> tout
>> leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
>> ( Referrers URLs: If the host in question accessed the site via another
>> resource, or was linked/diverted to you from another host, the URL they
>> were
>> referred from will be provided in this panel. See `--ignore-panel` in your
>> configuration file to enable it. (disabled by default) )
>>
>> Y'a un truc pour changer la période d'analyse ?
>> Là on a 31/Dec/2016 — 20/Nov/2017
>> Mais si je veux savoir comment a évolué la provenance des internautes
>> entre
>> décembre 2016 et décembre 2017 ?
>>
>>
>>
>>
>>
>>
>> -
>> --
>> sly, contact direct : sylvain /a\ letuffe o r g
>> http://wiki.openstreetmap.org/wiki/User:Sletuffe
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> 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
>
>


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

Re: [Talk-it] Editor ID e layer di sfondo

[Marco]

1. credo/temo di no

2. si, però la nuova heatmap funziona solo a livelli di zoom inferiori o 
uguali a 16, quindi si rischia che i sentieri mappati risultino un po' 
"spigolosi".


Qua trovi l'url da inserire nel livello personalizzato su iD

https://help.openstreetmap.org/questions/60485/strava-updated-heatmap

Ciao


Il 19/11/2017 23:03, Davide Sandona' ha scritto:

Ho un paio di domande riguardo l'editor online ID:
1. esiste la possibilità di caricare la cartografia PCN? Secondo la 
pagina wiki no, ma è vecchia di un paio d'anni... [1]
2. esiste la possibilità di utilizzare il layer Strava Heatmap sopra 
alle immagini satellitari, come su JOSM in cui la parte di color nero 
del layer non viene visualizzata?


[1]http://wiki.openstreetmap.org/wiki/WikiProject_Italy/PCN

Davide.


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


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

Re: [Talk-cz] Fungující transformace z Křováka!

[Jan Macura]

Ahoj,

2017-11-20 12:00 GMT+01:00 Petr Vejsada :

> tak hotovy všechny vrstvy (adresy, budovy, ulice, parcely, landuse,
> budovy-todo).


díky za tu práci.


> V budovách TODO přibylo asi 1300 kousků kvůli změně.


Kvůli změně v RÚIAN? Jakože vznikly (nově se postavily nebo zaměřily)? Nebo
to myslíš jinak?

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

Re: [OSM-talk] What would make MapRoulette better?

[Erwin Olario]

I wish to see support for OSM tags for tasks.

On Mon, Nov 20, 2017 at 5:02 AM Martijn van Exel  wrote:

> Hi all,
>
> For those who have used MapRoulette or at least have a good understanding
> of what it does: what would be the *one top thing* for you that would make
> it better?
>
> I am asking because I am working on a new major release.
> --
> Martijn van Exel
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-- 

/Erwin Olario

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

Re: [OSM-talk-fr] Stats serveurs de tuiles OSM-FR...

[Vincent Frison]

Effectivement c'est sexy !

Je suis étonné de voir que sur 38 TB seulement 15 viendrait de la France...


Le 20 novembre 2017 à 13:38, sly (sylvain letuffe)  a
écrit :

> Il est très sexy ce goaccess, mais si on gratte, il manque quand même
> quelques trucs bien utiles (c'est p'tet un truc qui s'active) :
>
> Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller
> tout
> leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
> ( Referrers URLs: If the host in question accessed the site via another
> resource, or was linked/diverted to you from another host, the URL they
> were
> referred from will be provided in this panel. See `--ignore-panel` in your
> configuration file to enable it. (disabled by default) )
>
> Y'a un truc pour changer la période d'analyse ?
> Là on a 31/Dec/2016 — 20/Nov/2017
> Mais si je veux savoir comment a évolué la provenance des internautes entre
> décembre 2016 et décembre 2017 ?
>
>
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Stats serveurs de tuiles OSM-FR...

[sly (sylvain letuffe)]

Il est très sexy ce goaccess, mais si on gratte, il manque quand même
quelques trucs bien utiles (c'est p'tet un truc qui s'active) :

Dans les referers il annonce "www.free.fr" en 14ème place mais fouiller tout
leur site pour trouver à quelle page ils s'en servent, c'est pas aisé !
( Referrers URLs: If the host in question accessed the site via another
resource, or was linked/diverted to you from another host, the URL they were
referred from will be provided in this panel. See `--ignore-panel` in your
configuration file to enable it. (disabled by default) )

Y'a un truc pour changer la période d'analyse ?
Là on a 31/Dec/2016 — 20/Nov/2017
Mais si je veux savoir comment a évolué la provenance des internautes entre
décembre 2016 et décembre 2017 ?






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-us] Multipolygonizing

[Mike N]

On 11/19/2017 5:48 PM, Douglas Hembry wrote:

I told glebius that I wanted to find out  what the
community thought. Is this just one more valid optional way of mapping?
To be recommended for adoption if possible? Or to be avoided? Thoughts?


  I have this situation locally where much of the adjacent landuse was 
created as multipolygon.  It definitely takes longer to modify these 
areas for new construction.  That is in JOSM without that special 
toolbox which I hadn't used before.


  I can't imagine what it must be like for a newcomer (with any editor).


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

Re: [OSM-talk-fr] Marquage et jalonnement en randonnée

[sly (sylvain letuffe)]

Nicolas Dumoulin-2 wrote
> Quelques exemples ici :

Et ben mon vieux ! Tu nous illustres le fait de tagguer "name" sur les
panneaux de rando et on a un contre jour, un flou, et un arraché.
Pas évident de juger de la pertinence du "name" sur tes exemples :-)
Mais je suppose que ceux qui participent au débat ici on bien en tête ce
qu'est un panneaux de rando avec un nom indiqué dessus.


Nicolas Dumoulin-2 wrote
> En effet, il s'agit ici du nom du "nœud" dans le réseau de randonnée.
> (...)
> (Exemple avec) le nom des gares ou des arrêts de bus reprenant les
> toponyme.

Je n'avais pas pensé à cette manière de voir les panneaux de rando comme "un
réseau interconnecté".
Dans cette optique là, en effet, un panneaux pourrait avoir un nom du "point
du réseau" même s'il est éventuellement identique à celui du truc réél non
loin.
Ainsi, comme pour les lignes de Bus/métro/.., lorsque l'on considère
l'ensemble des arrêts d'une ligne, au sein de cette ligne, chacun à un nom.
Mouais.
Je pourrais me laisser convaincre par cette argumentation, si ce n'est que
je n'ai pas l'impression, quand je fais mes rando de voir "des lignes ou
réseau de panneaux".
Il m'arrive de croiser des "bout de carte" qui décrivent des randos
suggérées (des itinéraires quoi), mais je doute que tous les panneaux y
figurent, et j'ai plus l'impression qu'on me pointe les éléments du terrains
plutôt que des panneaux de repérage.


Nicolas Dumoulin-2 wrote
> Par rapport à l'exemple du col, dont on ne préciserait pas le nom car un 
> poteau avec le nom du col existe déjà : j'ai un peu envie de dire que 
> c'est la faute du rendu ou de l'outil. Si on affiche "panneau indicateur 
> 'col truc'", ça lève un peu l'ambiguïté. 

Comme je disais, je pense que les outils d'usage finiront par ignorer les
name des panneaux pour éviter la confusion et les doublons, donc ce
désagrément devrait être réduit. Par contre, les outils d'édition eux ont
pour rôle de montrer ce qui est dans la base, donc ils devaient logiquement
continuer à indiquer "col truc" sur le panneau et, j'en ai peur, dissuader
de l'ajouter.
D'où ma dernière suggestion sur le wiki, de bien indiquer que le nom sur le
panneaux ne remplace pas le nom sur le point réél, et espérer que les
éditeurs auront une démarche visant à réduire les risques d'oubli
("panneau du col truc", "icône en gros", "texte en petit", que sais-je
d'autre comme bonne idée)




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [talk-au] [Aust-NZ] FOSS4G-ANZ?

[David Dean]

Agreed. Very interested in keeping momentum here. I have relationships with
QUT, UQ and Griffith in Brisbane if that helps (although organising smaller
OSM events through any of them has not been successful yet).

Also, we have been discussing some of this on the MaptimeAU slack, in the
#sotm channel, and if anyone would be interested in joining, they would be
welcome. Ask for an invite at https://bit.ly/maptimeau.

I know that people on the Spatial Community Slack would also be interested:
you can get to them at http://thespatialcommunity.org/. Join the
#loc-australia channel for them.

- David

On Mon, 20 Nov 2017 at 21:03 adam steer  wrote:

> Great! Also lots of choice of reasonable climates that time of year…
>
> this is an excellent thread, hope to help keep the flames fanned!
>
> On 20 November 2017 at 21:59, Alex Leith  wrote:
>
>> I suggest later in the year, so Oct/Nov next year should be achievable.
>>
>> On Mon, 20 Nov 2017 at 9:55 pm, adam steer 
>> wrote:
>>
>>> Hi all
>>>
>>> agree with Cameron’s points, and Alex’s, and Toby’s. as a fundamental
>>> step, what needs doing to get support from osgeo? formalising the ANZ
>>> chapter?
>>>
>>> I’ll ask around at ANU/CSIRO here in CBR also for venue costs/support.
>>>
>>> Fundamental other question: would we want to get this going - in 2018?
>>> Could I suggest winter or summer - international f4G is usually August-ish,
>>> Locate is April-ish - what about June/July-ish or December-ish for
>>> ‘foss4g-anz’?
>>>
>>> Cheers
>>> Adam
>>>
>>>
>>>
>>> --
>>
>> Alex Leith
>> 0419 189 050
>>
>
>
>
> --
> Adam Steer
> https://www.researchgate.net/profile/Adam_Steer
> http://au.linkedin.com/in/adamsteer
> http://orcid.org/-0003-0046-7236
> +61 427 091 712 <0427%20091%20712>
> skype: adam.d.steer
> tweet: @adamdsteer
> ___
> Aust-NZ mailing list
> aust...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/aust-nz

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

Re: [Talk-cz] Fungující transformace z Křováka!

[Petr Vejsada]

Ahoj,

tak hotovy všechny vrstvy (adresy, budovy, ulice, parcely, landuse, 
budovy-todo). V budovách TODO přibylo asi 1300 kousků kvůli změně.

Posun v Jablunkově vůči KM je dle Qgisu 2.7 cm, viz obrázek. Je to zase ta 
plackárna u autobusového nádraží.

Lepší to se stávajícím gridem nebude. Ty necelé 3cm tuším zcela odpovídají 
deklarovaným vlastnostem toho gridu.

Petr


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

Re: [Talk-cz] Fungující transformace z Křováka!

[Marián Kyral]

-- Původní e-mail --
Od: Ha Noj 
Komu: OpenStreetMap Czech Republic 
Datum: 20. 11. 2017 10:23:32
Předmět: Re: [Talk-cz] Fungující transformace z Křováka!
"Dne 20. listopadu 2017 10:16 Marián Kyral  napsal(a):
>
> -- Původní e-mail --
> Od: Ha Noj 
> Komu: OpenStreetMap Czech Republic 
> Datum: 20. 11. 2017 10:06:52
> Předmět: Re: [Talk-cz] Fungující transformace z Křováka!
>
>> jak tak na to koukám, přijde mi, že se možná posunul i katastr. Protože
>> mám
>> všechny budovy mírně posunuté. I ty, které mi předtím určitě seděly na
KM.
> *** vrstva KM může mít jiný typ transformace. Nikdy se mi nepodařilo
> vyrazit info z CUZK, jaká to je.
>
>
> Jo to vím. Právě že Petr narazil na nastavení, které se KM hodně blíží.
Ale
> může to být i tím, že se možná změnila i transformace u KM. To byla pointa
> mého emailu.
*** já zase naznačuju, že u wms cuzk:km nemuselo dojít ke změně, ale
trvalému použití méně přesné transformace. Už proto že wgs84 je mimo
jeho hlavních rámec zájmů. ;)
"



Takže, čistě teoreticky, k nějaké změně dojít mohlo. Zpřesnili přepočet,
nainstalovali novou verzi sw…  :-D




Marián

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

Re: [Talk-cz] Fungující transformace z Křováka!

[Ha Noj]

Dne 20. listopadu 2017 10:16 Marián Kyral  napsal(a):
>
> -- Původní e-mail --
> Od: Ha Noj 
> Komu: OpenStreetMap Czech Republic 
> Datum: 20. 11. 2017 10:06:52
> Předmět: Re: [Talk-cz] Fungující transformace z Křováka!
>
>> jak tak na to koukám, přijde mi, že se možná posunul i katastr. Protože
>> mám
>> všechny budovy mírně posunuté. I ty, které mi předtím určitě seděly na KM.
> *** vrstva KM může mít jiný typ transformace. Nikdy se mi nepodařilo
> vyrazit info z CUZK, jaká to je.
>
>
> Jo to vím. Právě že Petr narazil na nastavení, které se KM hodně blíží. Ale
> může to být i tím, že se možná změnila i transformace u KM. To byla pointa
> mého emailu.
*** já zase naznačuju, že u wms cuzk:km nemuselo dojít ke změně, ale
trvalému použití méně přesné transformace. Už proto že wgs84 je mimo
jeho hlavních rámec zájmů. ;)

d.

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

[Talk-it] Rivenditore oli lubrificanti

[Andreas Lattmann]

Buongiorno, come si taggano i rivenditori in oggetto?
Vendono anche batterie per auto.

Grazie

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

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