[Talk-at] Einladung: Stammtisch Obersteiermark, 19.01.2017 (Donnerstag)

[Borut Maricic]

Herzliche Einladung zum OpenStreetMap-Stammtisch
Obersteiermark!

Wann: Donnerstag, 19.01.2017, 18:00 Uhr
Wo: "Zum Italo-Steierer", Bachgasse 8, Leoben (Stadtteil Göß)
Tischreservierung: Auf „OpenStreetMap“

Die Themen und Fragen können hier nachgeschaut und erweitert
werden:

https://wiki.openstreetmap.org/wiki/Leoben/Stammtisch

Liebe Grüße,
Borut (Borut@OSM)


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

Re: [OSM-talk-be] Groen in de steden

[Marc Gemis]

In welke changeset heeft ze die wijziging gedaan ? Kunnen we dat reverten ? :-)

Serieus, dit is iets dat
natural=tree_row;leaf_type=broadleaved;leaf_cycle=deciduous moet zijn.
Ik ben geen boomkenner, dus taxus kan ik niet invullen.

BTW, landuse=forest betekent niet noodzakelijk landcover=trees. Als de
bomen gekapt zijn, staan er voor korte of lange tijd geen bomen op dat
perceel.

Nog een probleem bij landuse: het aansluiten van bos aan veld/weide
als er een pad in het spel is. Op de kaart is het mooi dat er geen wit
tussen beide gebieden, maar als gebruiker van de kaart wil je
feitelijk weten of het pad niet nog een stukje door het bos gaat (zie
foto's [1],[2],[3], op de grens ligt of een stukje in het veld. Dit
laatste komt in de praktijk niet zoveel voor. Maar op luchtfoto's
komen de kruinen van de bomen altijd verder, de landuse=forest wordt
bijna steeds te breed getekend.

Dus als je vertrouwd bent met zo'n situaties, pas de kaart aan aub.
Maar, sluit geen landuses aan aan lijnen van paden en wegen. Bij wegen
is dat gemakkelijk, bij paden met bijna geen breedte toch een aparte
lijn tekenen. En voor de die-hards, ook niet eens een lijntje tekenen
voor de afsluiting of gracht of een multi-polygon van het gebied maken
en de barrier tags op de lijn, de landuse tags op de multi-polygon.

Nog een leuk vraagje: behoort een gracht tot het weiland ernaast ? En
het gras tussen gracht en weg, is dat ook nog weiland ?

m.

[1] https://xian.smugmug.com/OSM/OSM-2017/2017-01-08-Bevel-Nijlen/i-FdqB5gs
[2] https://xian.smugmug.com/OSM/OSM-2017/2017-01-08-Bevel-Nijlen/i-NvsCQGj
[3] https://xian.smugmug.com/OSM/OSM-2017/2017-01-08-Bevel-Nijlen/i-2tm2TzW

2017-01-14 0:06 GMT+01:00 Ben Laenen :
> On Friday, 13 January 2017 13:24:39 CET Jasper Michels wrote:
>> Momenteel gebruik ik hier: Landuse=forest
>> Maar volgens de wiki is dit enkel voor echte bossen.
>
> But, but, but... 
> http://www.gva.be/cnt/dmf20160628_02360973/italielei-en-amerikalei-zijn-volgens-joke-schauvliege-bos
>  :-(
>
> ;-)
> Ben
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [Talk-us] cardinal directions

[Paul Johnson]

On Fri, Jan 13, 2017 at 3:42 PM, Martijn van Exel  wrote:

> Hi all,
>
> Some of you may remember the discussion we had on tagging cardinal
> directions in the US, which led to the wiki page[1] describing the current
> practice.
> Basically the convention we arrived on is to tag relation members with
> role=north/east/south/west to indicate cardinal direction.
> This is backed up by usage in the US. About 75% of way members of
> Interstate road relations have directional role members[2].
>

Can we *not* do this?  Can this *not* be a thing?  Can we instead go route
master and only have child *relations* have cardinal roles, with child ways
being exclusively forward/backward?  Because cardinal directions on the
ways themselves is 1) ambiguous AF and 2) breaks validation on a level that
it can take hours to days for experienced editors to manually validate, and
can't be automated as a result.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Adresses...

[Philippe Verdy]

Le 13 janvier 2017 à 21:52,  a écrit :

> De facto je suis dans un hameau d'une commune de plus de 2 000 habitants
> et les routes ne sont pas toutes nommées, les bâtiments pas numérotés et le
> lieu-dit n'a pas de panneaux (la complète, sauf que des panneaux
> indicateurs sur deux des trois routes indiquent la direction).
>

Si la commune a plus de 2000 habitants, elle doit obligatoirement avoir une
liste des voies publiques et privées (la numérotation n'est pas obligatoire
mais il doit y avoir des noms de localités ou de batiments/lieux-dits).
Normalement cette liste devrait être communiquée au cadastre. Les communes
de moins de 1 habitants confient cette tâche à leur communauté de
communes mais elle doit prendre les décision de dénomination. Dans les
faits toutes n'ont pas fait ce travail et ce sont les résidents eux-mêmes
qui ont nommé leurs adresses (souvent avec des lieux-dits) et l'ont
communiqué à la poste, ce qui peut faire apparaitre des disparités avec le
cadastre (et le FANTOIR).

Cependant la poste et les communes maintenant peuvent fusionner leurs
données et mettre à jour leurs plans municipaux avec les données de base
(au moins les noms des voies publiques, mais souvent les voies privées sont
oubliées). Espérons que le travail sur la BAN va aider à régler ces
disparités. En attendant dans OSM on a la BANO et les données collectées
localement. Avec les nombreuses fusions de petites communes de plus en plus
d'entre elles vont devoir faire ce travail parce que la réglementation les
y oblige. Depuis que presque tout le territoire est couvert par les EPCI
(homis les îles), la taille minimale est atteinte et les EPCI et communes
nouvelles doivent se mettre à jour. Mais il reste encore pas mal de toutes
petites communes et il en reste plein encore à vectoriser. et les plans
pour le faire s'étalent sur des années (avec des aides des départements et
régions pour les EPCI les plus ruraux).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Route verte 1 a perdu plus de 2000 km de voies

[Andy Townsend]

On 13/01/2017 20:58, Alouette955 wrote:

Bonjour,
Je viens de m’apercevoir que la relation Route verte 1 (416115) ne 
fait plus que 0,7 km ... Puisque afficher l’historique des 
modifications est impossible sur un si gros objet (erreur du serveur) 
je ne peux être certain de ce qui est arrivé.


Both PierZen and I have restored "full" versions (739 and 740 respectively).

If my version's wrong (which was of 737, not 736) please revert it.

https://www.openstreetmap.org/changeset/45148739 is Pierzen's change; 
https://www.openstreetmap.org/changeset/45150748 ws mine.


I'd definitely suggest making this a super-relation composed of smaller 
relations.  A relation with 2200 members is going to break regularly.


Best Regards,

Andy

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

Re: [OSM-talk-be] Groen in de steden

[Ben Laenen]

On Friday, 13 January 2017 13:24:39 CET Jasper Michels wrote:
> Momenteel gebruik ik hier: Landuse=forest
> Maar volgens de wiki is dit enkel voor echte bossen.

But, but, but... 
http://www.gva.be/cnt/dmf20160628_02360973/italielei-en-amerikalei-zijn-volgens-joke-schauvliege-bos
 :-(

;-)
Ben


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

Re: [Talk-ca] Route verte 1 a perdu plus de 2000 km de voies

[Pierre Béland]

J'ai fait un revert vers la version 736, soit avant intervention de ce 
contributeur (versions 737 et 738). Il a sans doute effacé par erreur.
Tu peux discuter de la suite avec lui et voir s'il a besoin d'aide pour modfier.
 Pierre 


  De : Alouette955 
 À : talk-ca  
 Envoyé le : vendredi 13 janvier 2017 15h58
 Objet : [Talk-ca] Route verte 1 a perdu plus de 2000 km de voies
   
Bonjour, Je viens de m’apercevoir que la relation Route verte 1 (416115) ne 
fait plus que 0,7 km ... Puisque afficher l’historique des modifications est 
impossible sur un si gros objet (erreur du serveur) je ne peux être certain de 
ce qui est arrivé. Par contre je soupçonne le groupe de modifications 45135059 
d’être en cause. J’ai contacté le contributeur (oanac2_telnav) et attend la 
réponse. Au cas où ce ne viendrait pas de ce dernier avez-vous un autre moyen 
de détecter le groupe de modification qui aurait pu donner ce résultat? Merci, 
P.S. For english speaking reader ... this message is about a big relation who 
lost almost all it’s members. I am not able to access history of modifications 
to track the problem.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

Re: [Talk-GB] Reversing the flow of a one-way street

[David Woolley]

On 13/01/17 22:44, Lester Caine wrote:

You simply reverse the direction the way is drawn. What editor are you
using as it's fairly obvious on all of them which direction a way has
been input.


I think you will find that JOSM defaults to also changing the oneway to 
oneway=-1 so there is no net change; you need to override that default 
behaviour, or use oneway=-1 in the first place.


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

Re: [OSM-talk-fr] Adresses...

[Erwan Salomon]

> 
> > Après numérotation d’une voie, fournir les plaques de numérotation (format 
> > standard - fond
> > bleu, écriture blanche) pour éviter les plaques exotiques et parfois peu 
> > lisibles ;
> Mon voisin va dire que ma commune s'est illustrée pour ses plaques exotiques 
> pour les noms de rues, des hameaux et des numéros.
> 
> Jean-Yvon

tes plaques je crois que je vais les cartographier comme des œuvres d’art … (à 
Caudan elles valent le détour aussi)
;-)
c’est vrai que certaines il faut connaitre le nom de la rue pour pouvoir les 
lires

et ils disent quoi sur les presque homonymes ?
les fautes d’orthographes ?
les rues qui comportent plusieurs panneaux discordants ?

ce qui est marrant avec toute cette bonne volonté, c’est que les gens on change 
pas leur habitudes facilement, alors même à numéroter et nommer/renommer les 
rues
de façon cartésienne, ils continuent à donner leur ancienne adresse et c’est le 
facteur débutant qui galère
« oui mais le facteur sait que y’a 30 ans ici c’était le chemin de Kerlavret » 
haha

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

Re: [Talk-GB] Reversing the flow of a one-way street

[Mark Goodge]

On 13/01/2017 22:44, Lester Caine wrote:

On 13/01/17 22:36, Mark Goodge wrote:

There is a one-way street (to be more precise, a service road) in my
town centre which has the wrong direction of flow on OSM. I can't see
any obvious way of changing that - the "oneway" tag merely has a value
of "yes", and there's no direction attribute anywhere that I can see.

Is it simply a case of deleting the way and re-adding it in the right
direction, or is there a better solution?


You simply reverse the direction the way is drawn. What editor are you
using as it's fairly obvious on all of them which direction a way has
been input.


Ah, OK. That's a link that I simply hadn't spotted I could click. I'm 
using the default iD editor.


Mark


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

Re: [Talk-GB] Reversing the flow of a one-way street

[Andy Townsend]

On 13/01/2017 22:36, Mark Goodge wrote:
There is a one-way street (to be more precise, a service road) in my 
town centre which has the wrong direction of flow on OSM. I can't see 
any obvious way of changing that - the "oneway" tag merely has a value 
of "yes", and there's no direction attribute anywhere that I can see.


Is it simply a case of deleting the way and re-adding it in the right 
direction, or is there a better solution? 


Most of the editors have a "make it go backwards" option.  The one in iD 
is the double chevron << with a tooltip of of "Make this line go in the 
opposite direction".


What's supposed to happen is that the editors are supposed to do 
"sensible" things with other tags (e.g. forwards / backwards relation 
memberships) - but I'd check those too just to make sure.


Best Regards,

Andy


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

Re: [Talk-GB] Reversing the flow of a one-way street

[Lester Caine]

On 13/01/17 22:36, Mark Goodge wrote:
> There is a one-way street (to be more precise, a service road) in my
> town centre which has the wrong direction of flow on OSM. I can't see
> any obvious way of changing that - the "oneway" tag merely has a value
> of "yes", and there's no direction attribute anywhere that I can see.
> 
> Is it simply a case of deleting the way and re-adding it in the right
> direction, or is there a better solution?

You simply reverse the direction the way is drawn. What editor are you
using as it's fairly obvious on all of them which direction a way has
been input.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[Talk-GB] Reversing the flow of a one-way street

[Mark Goodge]

There is a one-way street (to be more precise, a service road) in my 
town centre which has the wrong direction of flow on OSM. I can't see 
any obvious way of changing that - the "oneway" tag merely has a value 
of "yes", and there's no direction attribute anywhere that I can see.


Is it simply a case of deleting the way and re-adding it in the right 
direction, or is there a better solution?


Mark

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

Re: [OSM-talk] weeklyOSM #338 03/01/2016-09/01/2017

[Eduardo A. Mayorga]

On 01/13/2017 01:05 PM, weeklyteam wrote:

> The weekly round-up of OSM news, issue # 338,
> is now available online in English, giving as always a summary of all things 
> happening in the openstreetmap world:
>
> http://www.weeklyosm.eu/en/archives/8595/

I just wanted to point out that the crowdfunding campaign from the
Nicaraguan OSM community is not to make the first bus map in the
country (we already had a successful campaign that allowed us to achieve
that), but to
* improve the accuracy bus frequency data in Managua by having
  volunteers (who would get stipends) surveying with the Flocktracker
  mobile application
* convert the data into GTFS (a common format for digital public
  transport information)
* make the information publicly available
* assess the impacts of doing so, thanks to the hard work of MIT
  researchers

There are already data collected on bus lines schedules, but our goal
is to make it much more accurate.

Eduardo


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

Re: [Talk-GB] beetroot or beet

[Warin]

:)

Ok...

beets are vegetables.. (I hope). I do like an organised tagging scheme, so I am 
using produce=vegetable, then vegetable=*

This have two effects;

a better organisation structure and

the possibility to tag a field as produce=vegetable without specifying the 
vegetable.

It also places the issue of beet/beetroot/sugar-beet at a lower level.

I think the use of the abbreviation beet should be discouraged at that level.

I encourage doing the same for other produce ..e.g. nuts ... grains?

The present landuse=orchard has fruits so I'm not doing those as it presently 
uses its own scheme.


On 10-Jan-17 08:30 PM, Andy Robinson wrote:

I can see a whole new wiki excursion into the underground world of root crops 
;-)

Cheers
Andy

-Original Message-
From: Craig Wallace [mailto:craig...@fastmail.fm]
Sent: 10 January 2017 01:52
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] beetroot or beet

On 2017-01-10 01:20, David Groom wrote:

Although "beet" could also refer to "sugar beet"

Or "fodder beet" (aka mangelwurzel).
I think it is rather similar to sugar beet, not sure if you could tell the 
difference in the field.

It seems they are all the same species (Beta vulgaris), but different 
cultivars. Also Swiss chard is the same species, but using the leaves.


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


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




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

[Talk-us] cardinal directions

[Martijn van Exel]

Hi all, 

Some of you may remember the discussion we had on tagging cardinal directions 
in the US, which led to the wiki page[1] describing the current practice.
Basically the convention we arrived on is to tag relation members with 
role=north/east/south/west to indicate cardinal direction.
This is backed up by usage in the US. About 75% of way members of Interstate 
road relations have directional role members[2].

The Canadian highway system seems to follow similar conventions, having 
cardinal directions signposted. (Just picking out one example, [3])

The Telenav mapping team wants to help map cardinal directions in Canada now, 
and I have a few questions:
1) Is this way of tagging cardinal directions acceptable to the Canadian 
community as well?
2) For which regions / highways / highway types is it common to refer to the 
cardinal direction as part of the name?
2) How to deal with (mostly) single carriageways?

Posting to talk-ca and talk-us cc tagging because I think all three groups may 
have valuable input.

[1] http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States 

[2] See some number crunching here: 
https://gist.github.com/72a02709cecebfb7fcd563e701f4f064 
[3] http://openstreetcam.org/details/8671/13 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Adresses...

[osm . sanspourriel]

Je vois que selon Jean-Martial, FesseDeBouc c'est le cloud du spectacle ;-).
Moi aussi je me lâche !
Si les gens veulent ajouter un contact:FesseDeBouc, je ne vais pas 
l'enlever.

Par contre ne pas me demander de le mettre.
Un numéro de téléphone, une adresse internet c'est plus ou moins neutre 
(pas/peu de référence explicite de l'opérateur sous-jacent.

Tel n'est pas le cas des réseaux asociaux.

Oui pour mettre les infos temporaires dans OEDb.

> 
http://cms.geobretagne.fr/sites/default/files/documents/aitf.sig_.topo-_adresse_-_les_procedures_legales_et_les_bonnes_pratiques_en_vigueur_v_1.0.pdf


> Qu'en pensez-vous?
Un pensum.

De facto je suis dans un hameau d'une commune de plus de 2 000 habitants 
et les routes ne sont pas toutes nommées, les bâtiments pas numérotés et 
le lieu-dit n'a pas de panneaux (la complète, sauf que des panneaux 
indicateurs sur deux des trois routes indiquent la direction). Galère 
pour les livreurs (je mets en général la localisation GPS). Après 
quelques fêtes de voisins on arrive mieux à aider les livreurs. Plus 
gênant pour les secours.
Surtout quand le nom du lieu-dit est un toponyme... ne correspondant pas 
à la situation.
Selon http://tile.openstreetmap.fr/~cquest/leaflet/bano.html 
 le hameau est 
numéroté mais c'est le seul endroit où j'ai vu mon numéro comme celui 
des voisins.

C'est formellement se mettre en conformité par rapport à la loi.
Devrait-on forcer l'information dans OSM afin d'initier son usage ?

> Le numérotage est, de ce fait, obligatoire dans ces communes.
Mais comme en France on a des textes mais personne pour veiller à leur 
application...


Pas mal de remarques de bon sens.

> Opter pour des libellés de rue concis et veiller à ce que la 
dénomination soit adaptée à la

longueur de la voie pour permettre sa représentation sur un plan ;
On appelle ça l'amendement "venelle du Maréchal Jean de Lattre de 
Tassigny" ? ;-)


> Eviter de créer des voies trop courtes avec très peu d’habitations ;
Ça se comprend mais ils oublient de dire de le faire intelligemment :
http://www.openstreetmap.org/#map=19/47.78495/-3.49037=N
Un seul nom pour le lotissement sauf que les deux maisons de l'impasse 
au nord-est donnent non sur cette rue mais sur une autre.

Il aurait mieux valu donner des numéros de l'autre rue à ces deux maisons.
Préciser donc que la rue doit être contigüe.

Ne pas renommer les rues : sauf aussi en cas de découpe par un axe majeur.
http://www.openstreetmap.org/way/23979736#map=16/48.0989/-1.6134=N
La rue du Chêne Morand est de part et d'autre de la rocade dont une 
seule maison d'un côté.
On a aussi vu un 44 tonnes vouloir livrer un magasin dans la rue des 
Loges et se retrouver au bout de l'impasse 
http://www.openstreetmap.org/way/26180342 car sur la carte il n'avait 
pas vu le petit trait entre la rue et la voie principale.

Non la zone de retournement n'est pas prévue pour un 44 t.


> Sur la délibération, veiller à écrire la dénomination sous 2 formes :
> ○ avec une majuscule en début de nom et le reste en minuscule accentuée
> ○ en majuscule.
C'est au cas où des Alsaciens voudraient que des ä deviennent des AE ? 
J'ai du mal à comprendre l'intérêt de la version majuscule, le français 
étant une langue bicamérale. Des accents risquent de disparaître pour 
cause de configuration du logiciel du secrétaire de mairie.


> Pour la numérotation de plusieurs lieux-dits contigus, ne pas faire 
une numérotation en
> continu mais reprendre la numérotation à chaque changement de 
dénomination (celle-ci doit

> être soulignée par un panneau de lieu-dit) ;
Et quand on reprend des noms de rues suite à des fusions, que doit on 
inciter à faire ?
Si b et c fusionnent alors qu'elles sont entre A et D, on a facilement 
des route de A - route de D - route de A - route de D.
On pourrait conseiller de garder les parties externes et de renommer les 
routes de l'intérieur.


> Après numérotation d’une voie, fournir les plaques de numérotation 
(format standard - fond
> bleu, écriture blanche) pour éviter les plaques exotiques et parfois 
peu lisibles ;
Mon voisin va dire que ma commune s'est illustrée pour ses plaques 
exotiques pour les noms de rues, des hameaux et des numéros.


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

semanarioOSM Nº 338 03/01/2016-09/01/2017

[weeklyteam]

Hola, el semanario Nº 338, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8595/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

semanarioOSM Nº 338 03/01/2016-09/01/2017

[weeklyteam]

Hola, el semanario Nº 338, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8595/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

semanarioOSM Nº 338 03/01/2016-09/01/2017

[weeklyteam]

Hola, el semanario Nº 338, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8595/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

[Talk-ca] weeklyOSM #338 03/01/2016-09/01/2017

[weeklyteam]

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

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

Enjoy!

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

semanarioOSM Nº 338 03/01/2016-09/01/2017

[weeklyteam]

Hola, el semanario Nº 338, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en español:

http://www.weeklyosm.eu/es/archives/8595/

¡Disfruta!

semanarioOSM?
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-GB] weeklyOSM #338 03/01/2016-09/01/2017

[weeklyteam]

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

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

Enjoy!

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

[OSM-talk] weeklyOSM #338 03/01/2016-09/01/2017

[weeklyteam]

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

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

Enjoy!

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

[OSM-talk-ie] weeklyOSM #338 03/01/2016-09/01/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [OSM-talk-be] (no subject)

[Guy Vanvuchelen]

Fijne leerrijke discussie. Daar kun je wat van opsteken. 


Guy Vanvuchelen

-Oorspronkelijk bericht-
Van: Glenn Plas [mailto:gl...@byte-consult.be] 
Verzonden: vrijdag 13 januari 2017 18:16
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] (no subject)

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes 
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik 
> toch iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is nogaltijd een 
auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. 
> Indien dit wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien 
> we masaal landuse vervangen door landcover zal de kaart al maar witter 
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet 
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om 
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies gaan 
mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we gewoon niet 
doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven  >:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe  >:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
> ]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
> landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat
> landuse=grass niet echt juist is, misschien enkel voor gebieden
> waar graszodes geteeld worden. Maar omdat het op de kaart
> getoond wordt, zie 

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

Le projet OpenEventDatabase m'intéresse.

À première vue, il semble effectivement plus approprié qu'OSM pour y verser les 
données sur les évènements spatio-temporels que nous récoltons.

Je comprends mieux.

Cela voudrait dire que nous pouvons contribuer à OSM avec certaines données, 
ainsi qu'à OEDb pour d'autres jeux de données, diaspora* et autres GNU social 
pour les animations sociales autour de la programmation culturelle qui nous est 
confiée.

Pour être franc, d'autres initiatives existent pour synchroniser et partager 
ses évènements (OpenAgenda par exemple ), mais les 
modèles nous ont laissé dubitatifs (dans le sens du biens commun, du projet de 
société, etc.)...

Je note aussi que, pour nous, qui dit évènement, dit aussi co-voiturage 
(toujours dans le sens du bien commun, bien sûr).

Or, le projet covoiturage-libre.fr se cherche un véritable nouveau souffle, 
tant communautaire que technologique... je pense qu'il y aurait moyen...

Work in progress...

Jean-Martial


- Mail original -
> De: "Christian Quest" 
> À: "Discussions sur OSM en français" 
> Envoyé: Vendredi 13 Janvier 2017 18:06:54
> Objet: Re: [OSM-talk-fr]  [DGW] Contribution entreprise aux données OSM
> 
> 
> 
> 
> 
> Le 13 janvier 2017 à 16:24, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM
> < jean-mart...@zitcom.fr > a écrit :
> 
> 
> 
> > De mon point de vue, pour diffuser l'info sur un spectacle, il est
> > préférable que ce soit dans un agenda culturel, plutôt que de
> > signaler dans une base de données géographique là où on a mis des
> > affiches pour signaler qu'il y a un spectacle... à un autre
> > endroit.
> > 
> > Pour ça, il y a un projet plus adapté... OpenEventDatabase ;)
> 
> Pour bien comprendre, cela voudrait dire que les tags contact, page
> Facebook et autres URL de cette pizzeria n'ont rien à faire sur OSM,
> mais devraient plutôt être «référencées» uniquement par Google,
> Facebook et autres Pages Jaunes? <
> https://www.openstreetmap.org/node/4239161089 >
> 
> contact:facebook
> https://www.facebook.com/Pizza-Tradition-526470680769739
> contact:phone +33 240202302
> contact:website http://www.pizzatradition.fr
> 
> 
> 
> 
> Non pas du tout.
> 
> 
> La pizzeria a une position géographique, on la décrit donc à cet
> endroit et pas ailleurs. On indique ici les différents moyens de la
> contacter, mais elle est bien présente physiquement à cet endroit.
> 
> 
> 
> 
> Pour un spectacle, il se passe à un endroit et à un moment donné, pas
> là où on met des affiches. Si on devait le faire figurer dans OSM,
> c'est à cet endroit qu'on devrait le faire... mais on ne le met pas
> dans OSM parce que c'est une information trop temporaire pour avoir
> sa raison d'exister dans OSM.
> 
> 
> C'est pour partager des informations très liée au temps (bien au delà
> des spectacles) que j'ai démarré OpenEventDatabase... car OSM n'a
> pas vocation à les accueillir. De mon point de vue, des affiches
> pour des spectacles n'auraient pas plus de pertinence dans OEDB, par
> contre le spectacle en lui même oui, bien sûr.
> 
> 
> 
> 
> Et si on pousse plus ploin, que toute information hors sémantique
> cartographique n'a rien à faire dans OSM?
> 
> 
> 
> 
> J'ai pas dit ça non plus. La sémantique décrit l'objet géographique,
> mais il y a une limite à cette description et du coup aussi aux
> types d'objets qu'on met ou pas dans OSM.
> 
> 
> 
> 
> En plus, c'est une vraie question! ;)
> 
> 
> 
> 
> Je sais bien...
> 
> 
> --
> 
> 
> 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-be] (no subject)

[Glenn Plas]

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
> iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is
nogaltijd een auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit
> wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien
> we masaal landuse vervangen door landcover zal de kaart al maar witter
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies
gaan mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we
gewoon niet doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven  >:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe  >:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
> ]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
> landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat
> landuse=grass niet echt juist is, misschien enkel voor gebieden
> waar graszodes geteeld worden. Maar omdat het op de kaart
> getoond wordt, zie je landuse=grass overal verschijnen. (ipv het
> correctere landcover=grass)
> 
> Landcover slaat op wat je op de grond vindt.
> 
> Volgens mij moet in een ideale OSM map, elke plek op aarde [1]
> tot 2 polygonen behoren:
> eentje met een 

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Christian Quest]

Le 13 janvier 2017 à 16:24, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM <
jean-mart...@zitcom.fr> a écrit :

>
> > De mon point de vue, pour diffuser l'info sur un spectacle, il est
> > préférable que ce soit dans un agenda culturel, plutôt que de
> > signaler dans une base de données géographique là où on a mis des
> > affiches pour signaler qu'il y a un spectacle... à un autre endroit.
> >
> > Pour ça, il y a un projet plus adapté... OpenEventDatabase ;)
>
> Pour bien comprendre, cela voudrait dire que les tags contact, page
> Facebook et autres URL de cette pizzeria n'ont rien à faire sur OSM, mais
> devraient plutôt être «référencées» uniquement par Google, Facebook et
> autres Pages Jaunes? 
>
> contact:facebookhttps://www.facebook.com/Pizza-Tradition-
> 526470680769739
> contact:phone   +33 240202302
> contact:website http://www.pizzatradition.fr
>
>
Non pas du tout.

La pizzeria a une position géographique, on la décrit donc à cet endroit et
pas ailleurs. On indique ici les différents moyens de la contacter, mais
elle est bien présente physiquement à cet endroit.


Pour un spectacle, il se passe à un endroit et à un moment donné, pas là où
on met des affiches. Si on devait le faire figurer dans OSM, c'est à cet
endroit qu'on devrait le faire... mais on ne le met pas dans OSM parce que
c'est une information trop temporaire pour avoir sa raison d'exister dans
OSM.

C'est pour partager des informations très liée au temps (bien au delà des
spectacles) que j'ai démarré OpenEventDatabase... car OSM n'a pas vocation
à les accueillir. De mon point de vue, des affiches pour des spectacles
n'auraient pas plus de pertinence dans OEDB, par contre le spectacle en lui
même oui, bien sûr.



> Et si on pousse plus ploin, que toute information hors sémantique
> cartographique n'a rien à faire dans OSM?
>
>
J'ai pas dit ça non plus. La sémantique décrit l'objet géographique, mais
il y a une limite à cette description et du coup aussi aux types d'objets
qu'on met ou pas dans OSM.



> En plus, c'est une vraie question! ;)
>
>
Je sais bien...


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

Re: [Talk-it] OSMit2017 a Genova 8-11 febbraio in FOSS4G

[Marcello]

On 13/01/2017 14:58, Alessandro Palmas wrote:
> Salve lista,
> a ieri sera erano 47 le proposte di interventi a FOSS4G-IT
> Ricordo che c'è tempo sino a stasera per compilare la form per le
> proposte d'intervento orale o poster. Per la sessione poster ricordo
> che è un formato A1 verticale e che dovrebbe perferibilmente avere in
> testa i loghi dell'evento (fate uno screenshot della testa della
> pagina http://www.dicca.unige.it/geomatica/foss4git_2017/ e siete a
> posto).
>
> Stamane ho aggiunto una mia sessione poster sugli strumenti di
> monitoraggio e controllo qualità. A tal riguardo vi chiedo se siete a
> conoscenza di qualche sito o tool particolare a parte i più famosi
> (osmose, OsmInspector, whodidit e gli strumenti di Pascal Neiss). Mi
> pare rilevante far conoscere sia ad alcuni OSMer che al pubblico tutti
> gli strumenti disponibili per le attività di monitoraggio e ricerca di
> potenziali errori.

Alessandro,
ti indico altri siti che uso, sicuramente noti perché ne sono venuto a
conoscenza tramite questa lista, ma che non hai citato:

http://keepright.ipax.at/report_map.php?lang=it
http://qa.poole.ch/
http://product.itoworld.com/map/group/12

>
> Alessandro Ale_Zena_IT
>
>
Ciao
Marcello

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

Re: [OSM-talk-be] (no subject)

[Jasper Michels]

Dank voor je antwoord Marc!

-Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
tussen de autostrades met zwerfvuil.
 Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
iets mooiere landschappen te zien.

-Ik ben zo iemand die momenteel elk rijtje bomen als forest map. Indien de
maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit wel
moet zal ik vrees ik snel de zin om dit te mappen verliezen. (resultaat
naar werk is bij mij nodig)
 Van zodra men ook de landcover zou renderen, is dit een ander verhaal.

-Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
 Zolang men de landcover niet rendert is dit echter onmogelijk. Indien we
masaal landuse vervangen door landcover zal de kaart al maar witter worden.
(ik weet dat we niet mogen mappen voor de kaart, maar niet iedereen is  een
medogenloze databese-addict...)

Op 13 januari 2017 om 17:39 schreef Sus Verhoeven :

> Of niet meer durven mappen. ;-)
>
> Sus
>
>
> 2017-01-13 16:55 GMT+01:00 Santens Seppe :
>
>> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
>> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
>> verbeteren wat we ooit verkeerd gemapt hebben :-)
>>
>> Seppe
>>
>> -Oorspronkelijk bericht-
>> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
>> Verzonden: vrijdag 13 januari 2017 14:14
>> Aan: OpenStreetMap Belgium
>> Onderwerp: [OSM-talk-be] (no subject)
>>
>> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
>> te lezen :-)
>>
>> Jasper,
>>
>> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
>> het hout gekapt wordt voor industriële doeleinden (bosbouw).
>> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
>> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
>> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
>> elk onderhouden bos echt voor bosbouw is.
>>
>> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
>> een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
>> groepje bomen.
>>
>> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
>> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>>
>> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
>> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
>> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
>> vertaalt (google translate). Dus dat pas wel.
>>
>> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
>> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
>> aan te pas komt ?
>>
>> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
>> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
>> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
>> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>>
>> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
>> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
>> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
>> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
>> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
>> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
>> verschijnen. (ipv het correctere landcover=grass)
>>
>> Landcover slaat op wat je op de grond vindt.
>>
>> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
>> polygonen behoren:
>> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
>> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
>> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
>> (amenity), etc. daarboven op gaan mappen.
>>
>> Dus voor een park
>> - leisure=park (doen we nu al)
>> - landuse=xxx (nog te definiëren)
>> - dan voor verschillende delen landcover=trees of grass of bushes of
>> sand, rocks, etc.
>> -
>> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
>> landuse=grass of forest.
>>
>>
>> Bij een woning met tuin
>> - landuse=residential
>> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
>> van het huis, terras, e.d. nog andere landcovers Dus hier geen
>> landuse=forest om de tuin aan te duiden. Er is geen bosbouw, er is ook geen
>> bos om te recreëren, dus waarom landuse=forest ? Dat is taggen voor de
>> renderer [1].
>>
>> Dat is volgens mij het doel van de landcover, om los van het gebruik
>> bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest terug
>> voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt worden voor
>> bossen met een recreatieve of natuurbeschermende bestemming.
>>
>> Landcovers 

Re: [OSM-talk-be] (no subject)

[Sus Verhoeven]

Of niet meer durven mappen. ;-)

Sus

2017-01-13 16:55 GMT+01:00 Santens Seppe :

> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
> verbeteren wat we ooit verkeerd gemapt hebben :-)
>
> Seppe
>
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
>
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
> te lezen :-)
>
> Jasper,
>
> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
> het hout gekapt wordt voor industriële doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
> elk onderhouden bos echt voor bosbouw is.
>
> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op een
> groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
> groepje bomen.
>
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>
> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
> vertaalt (google translate). Dus dat pas wel.
>
> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
> aan te pas komt ?
>
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>
> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
> verschijnen. (ipv het correctere landcover=grass)
>
> Landcover slaat op wat je op de grond vindt.
>
> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
> polygonen behoren:
> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
> (amenity), etc. daarboven op gaan mappen.
>
> Dus voor een park
> - leisure=park (doen we nu al)
> - landuse=xxx (nog te definiëren)
> - dan voor verschillende delen landcover=trees of grass of bushes of sand,
> rocks, etc.
> -
> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
> landuse=grass of forest.
>
>
> Bij een woning met tuin
> - landuse=residential
> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
> van het huis, terras, e.d. nog andere landcovers Dus hier geen
> landuse=forest om de tuin aan te duiden. Er is geen bosbouw, er is ook geen
> bos om te recreëren, dus waarom landuse=forest ? Dat is taggen voor de
> renderer [1].
>
> Dat is volgens mij het doel van de landcover, om los van het gebruik
> bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest terug
> voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt worden voor
> bossen met een recreatieve of natuurbeschermende bestemming.
>
> Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg nagedacht
> over landuses.
>
> Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)
>
> m
>
> p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je goed
> moet nadenken over de betekenis van een woord voor je het kan mappen. Wat
> is een park ? Wat is een tuin ? (of iets heel anders: ) wat is een
> parking/parkeerterrein ? (dit is niet hetzelfde als een
> parkeerplaats)
> p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had me
> er vroeger nooit zo bezig gehouden met het mappen van
> landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
> situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te lezen
> over het thema, vragen op mailing lists te volgen,  en dan ben je nog niet
> wijzer.
> p.s. Joost, je schreef ooit dat het gemakkelijker wordt als je meer weet
> over OSM, maar dat is niet waar, zie de vorige p.s. :-)
>
> [1] toch in de bewoonde wereld, op Antartica is landuse misschien niet
> nodig [2] 

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

> Il y a (eu?) effectivement des discussions sur la pertinence de
> mettre des données de contact dans OSM mais comme le principe de base d’OSM
> est que le terrain à raison, si ces informations sont disponibles sur le
> terrain, alors, elles peuvent être ajoutées à OSM.
> 
> Sur l’exemple que tu donnes, il me semble assez peu pertinent de
> citer l’adresse Facebook du restaurant, puisque son site web est déjà
> référencé. Dans mon esprit, ce serait au site web du restaurant
> d’indiquer ses pages Facebook, Tripmachin et autres liens utiles et
> pas à OSM (mais c’est peut-être lié à mes "affinités" avec ces services
> centralisé  :-) )

Oui, nous avons les mêmes affinités. :)

Je prone l'auto-hébergement, je ne crois pas au «cloud» (façon de parler) et 
pour moi aussi c'est à chaque site de référencer Facebook et non sur Facebook 
qu'il faut référencer son site.

Néanmoins, force est de constater qu'il est des gens pour qui Facebook sert de 
«site Internet» (et d'autres, plus «fous» encore pour qui Google c'est le 
Web... serieux!)

Qu'il y ait un tag officiel contact:facebook ne me choque pas.  C'est une 
question de cohérence, même si je n'aime pas Facebook.

> Pour aller plus loin et rebondir sur les propos de Christian, la
> problématique d’OSM est plus la "permanence" des données. Si les
> informations sont très vite obsolètes (je dirais un changement toute
> les semaines ou plus fréquent), alors ces données n’ont potentiellement
> pas leur place dans OSM.
> 
> On peut alors utiliser un autre projet qu’a proposé et commencé à
> développer Christian : OpenEventDatabase
> (http://openeventdatabase.org
> et https://github.com/openeventdatabase/).
> Dans cette base, le but est de référencer les événements en leur
> ajoutant une dimension géographique.
> 
> Il serait donc plus sans doute plus pertinent que les événements que
> vous couvrez soient dans OpenEventDatabase (OEDb).
> OSM n’est sans doute pas le bon projet pour stocker l’information des
> affiches posées sur tel panneau ; je ne sais pas dans quel mesure
> OEDb le serait… Peut-être cette information devra-t-elle rester dans votre
> SI.

«Aucun projet à l'heure actuelle ne propose de mettre en commun ce type de 
données. OpenStreetMap répond à quoi et où, mais pas à quand et n'a pas 
vocation à collecter des données historiques.»

Intéressant!  Je regarde ça.

Jean-Martial

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

[Talk-in] OSM Server - Local language not getting displayed

[VAMO Systems]

Dear All

I have managed to install the OSM server successfully. But local languages
fonts are not getting displayed properly.  Please have a look at this link

http://puccagps.com/Osm_index.html

I have run this step - sudo dpkg-reconfigure locales and installed all
font. Still not working. Any clues?

My server is Debian Linux 8. And I followed the below links to install the
OSM server.

https://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1604_tileserver_load#Updating_your_database_as_people_edit_OpenStreetMap
http://xsce.org/wiki/generating_map_tiles





Best Regards,
Prasanna K
Director - Product Engineering
VAMO Systems Private Limited 
2nd Floor, New No 21/Old No 8,
86th street, Ashok Nagar
Chennai, TamilNadu, India,600083
Mobile: +91-9840898818
Email: p...@vamosys.com
twitter: @gps_vamosystems
Skype: pkram76
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[frem]

Le 13/01/2017 à 16:24, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM a écrit :

De mon point de vue, pour diffuser l'info sur un spectacle, il est
préférable que ce soit dans un agenda culturel, plutôt que de
signaler dans une base de données géographique là où on a mis des
affiches pour signaler qu'il y a un spectacle... à un autre endroit.

Pour ça, il y a un projet plus adapté... OpenEventDatabase;)

Pour bien comprendre, cela voudrait dire que les tags contact, page Facebook et 
autres URL de cette pizzeria n'ont rien à faire sur OSM, mais devraient plutôt être 
«référencées» uniquement par Google, Facebook et autres Pages 
Jaunes?

Je m’invite dans la conversation  :-)

Il y a (eu?) effectivement des discussions sur la pertinence de mettre 
des données de contact dans OSM mais comme le principe de base d’OSM est 
que le terrain à raison, si ces informations sont disponibles sur le 
terrain, alors, elles peuvent être ajoutées à OSM.


Sur l’exemple que tu donnes, il me semble assez peu pertinent de citer 
l’adresse Facebook du restaurant, puisque son site web est déjà 
référencé. Dans mon esprit, ce serait au site web du restaurant 
d’indiquer ses pages Facebook, Tripmachin et autres liens utiles et pas 
à OSM (mais c’est peut-être lié à mes "affinités" avec ces services 
centralisé  :-) )



Pour aller plus loin et rebondir sur les propos de Christian, la 
problématique d’OSM est plus la "permanence" des données. Si les 
informations sont très vite obsolètes (je dirais un changement toute les 
semaines ou plus fréquent), alors ces données n’ont potentiellement pas 
leur place dans OSM.


On peut alors utiliser un autre projet qu’a proposé et commencé à 
développer Christian : OpenEventDatabase (http://openeventdatabase.org 
et https://github.com/openeventdatabase/).
Dans cette base, le but est de référencer les événements en leur 
ajoutant une dimension géographique.


Il serait donc plus sans doute plus pertinent que les événements que 
vous couvrez soient dans OpenEventDatabase (OEDb).
OSM n’est sans doute pas le bon projet pour stocker l’information des 
affiches posées sur tel panneau ; je ne sais pas dans quel mesure OEDb 
le serait… Peut-être cette information devra-t-elle rester dans votre SI.


frem
--
Contributeur OpenStreetMap .
Retrouvez aussi une partie des contributeurs OpenStreetMap de la Vienne 
aux permanences de l’APP3L .


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

Re: [OSM-talk-fr] Adresses... (encore)

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

Voies et adresses : les procédures légales et les bonnes pratiques en vigueur

).

Qu'en pensez-vous?

Jean-Martial


- Mail original -
> De: "Christian Quest" 
> À: "Discussions sur OSM en français" 
> Envoyé: Vendredi 13 Janvier 2017 15:17:38
> Objet: Re: [OSM-talk-fr] Adresses... (encore)
> 
> 
> 
> Un numéro d'adresse est à voir plutôt comme un repère ordonné le long
> d'une voie... ensuite il peut se passer plein de choses derrière: N
> parcelles, M bâtiments qui peuvent en plus être liés à d'autres
> adresses (accès multiples).
> 
> 
> Pour la BAN on a discuté aussi très longuement de tout ça et le
> consensus est resté sur le point de passage du domaine public au
> domaine privé.
> 
> 
> Le souci avec le raisonnement qui aboutit au bâtiment, c'est qu'on
> saute l'étape parcelle car elle est absente d'OSM. Elle fait en
> général le lien.
> 
> 
> 
> 
> Le 13 janvier 2017 à 16:10, Nicolas Moyroud < nmoyr...@free.fr > a
> écrit :
> 
> 
> 
> 
> 
> Cette discussion sera fin tant que tu n'auras pas conceptualisé
> l'adresse autrement que penser qu'elle se rapporte obligatoirement à
> un bâtiment.
> Pas forcément un bâtiment mais en tout cas l'adresse se rapporte à
> quelque chose. Et un point seul dans le vide ne rapporte à rien à
> part lui-même (sauf si tu le mets dans une relation comme je le
> disais précédemment). Et je pense également que cette discussion
> sera sans fin tant que certains n'auront pas conceptualisé ça.
> Je prends un exemple : tu as 4 entrées rapprochées au fond d'une
> impasse tu mets tes 4 numéros d'adresse les uns à côté des autres.
> Tu ne sais plus à quel objets se rapportent chacune des adresses (je
> dis objet volontairement pour que tu y mette ce que tu veux dans
> objet : bâtiment, parcelle).
> Donc c'est bien de mettre un numéro d'adresse tout seul, ça sert dans
> certains cas, mais il y a une perte d'informations et c'est dommage.
> 
> Nicolas
> 
> ___
> 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

Re: [OSM-talk-ie] What to do about sloppy mapping errors

[Rory McCann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adrian!

On 11/01/17 21:46, Adrian Thomas wrote:
> I've recently retired and moved to live in West Cork.  As an
> experienced hill walker I have been using GAIA GPS to explore new
> routes across the hills and mountains in the west of Ireland.

And welcome to OSM!

We have a few hillwakers here (in OSM Ireland and OSM globally). I
like a bit of hiking myself. There's a few hiking sites based on OSM:

 * https://hiking.waymarkedtrails.org/
 * http://hikebikemap.org/
 * General info about walking routes etc:
https://wiki.openstreetmap.org/wiki/Walking_Routes
 *
https://wiki.openstreetmap.org/wiki/Ireland/Irish_Waymarked_Walking_Trail_Network


> noticed that some local features such as buildings were missing
> from OSM so I enroled as a contributor a few months back.  I spent
> a happy evening adding local features which I know exist  using the
> aerial photo backdrop for accuracy.

Great stuff.

> I was quite disheartened next day when less than half of my new
> additions appeared on the map so I haven't been back.

That's a shame. As others have noted, it's a chance that your web
browser is caching the map images locally and isn't showing you the
new, updated ones. If you load the same area in an Incognito
mode/Private Browsing mode, it will not use that old cache and you
might see the data fresh. You can also clear your browser cache (this
page has guides: http://www.refreshyourcache.com/ ).

If it is the cache, and you do nothing, it should appear in about a
week (since your computer only caches it for about a week)

Another option is simple mistakes. A motorway is highway=motorway, if
you enter "highwya=motorway" it won't work. Happens to the best of us
sometimes :)

If you tell us the area, and what you expect to appear, we can have a
look and provide more specific feedback.

> However, I have recently noticed quite a number of significant
> errors on OSM in my locality and I'd really like to EITHER go in
> and correct someone else's carelessness OR simply report the
> error(s) and let someone else put them right.  I think I could
> contribute quite a lot to OSM in West Cork and Kerry simply by 
> checking out stuff which I suspect to be wrong.

That'd be great! If you want to fix the errors, go ahead! That's the
best and more straight forward approach. Just edit the map and fix it!
The closest thing to a "report" functionality is to leave a note on
the map. "A pub is missing here" that kind of thing. Though those sort
of notes are best dealt with by local mappers in the area, which
well... ;)

> For instance north of Bantry is a well known col shown as "Priest's
> Leap 572m" despite the fact that a) it isn't that high, b) it's
> shown below the 450m contour and c) even the nearby hill top is
> only 520m.  This isn't even a typo because it isn't 472m either!

Huh. It looks like that ( https://www.openstreetmap.org/node/332372918
) is from the Mountain View data import from 2009. Practically
prehistoric by OSM standards! The mountain view page is here
http://mountainviews.ie/summit/413/ I think others have explained how
"elevation" is tagged.

> Some of my other "errors" relate to features shown as roads which
> are actually overgrown tracks which you couldn't even walk along
> much less drive and certainly NOT a public road.

OSM is more than just roads. We can add walking paths and such.

> In one case there is a "track" across a field on OSM which was
> shown on the aerial photos as no more than the marks left by a
> tractor on one pass.  Definitely neither a road nor a track.

There's nothing wrong with this per se. If a farmer just drove across
a field on the day the aerial imagery was taken, and left an
indentation in the ground, then yes, don't map that. But if it's an
actual track, then by all means map that. You can use the tracktype
tag to specify the track quality, with tracktype=grade5 being like you
describe. https://wiki.openstreetmap.org/wiki/Key:tracktype

As I'm sure you know, if you're hiking, you would be willing to walk
down a tracktype=grade5.

> Am I authorised to start cleaning up these blunders or should I
> just go back to using OS maps?

Of course you are "authorised"! Everyone is authorised. There is no
authorisation for anyone to give or revoke. (It is possible to block
vandals though, lest you think we're an anarchy.)

If you can improve the map (either adding new data/information, or
correcting old data), then by all means do it! You don't need to ask
permission.

If you're worried about mistakes, you can tell us your OSM username,
and we can have a look over what you add, and give you any pointers
and double check what you've done. There are many tools in OSM to
"undo"/revent work that someone has added, so if you really mess up,
and want one of us to undo it for you, we can do that.

Hope that helps. Feel free to email this list (or me privately if
you'd like), if you have any more questions. We were all new once.

Rory

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

> [...] Indiquer ce qui se trouve sur ce panneau, c'est déjà moins neutre et
> c'est aussi très (trop) changeant pour que l'info soit fiable quand
> on la consulte.
> 
> C'est la limite d'OSM par rapport à de l'info très dynamique. On se
> pose le même genre de question pour des routes coupées par des
> travaux. Si ça dure vraiment (plusieurs semaines, mois, impact
> important), oui, on peut l'indiquer dans OSM.

Notre volonté est que les données de notre SI se synchronisent en temps réel 
avec les données d'OSM.

C'est à dire que quand nos afficheurs constatent une modification sur le 
terrain qu'ils arpentent tous les jours (contacts, horraires d'ouverture, nom 
de l'enseigne, changement d'établissement, porte d'entrée derrière le bâtiment, 
etc.), ils effectuent les modifications dans notre SI, puis notre SI met à 
jours tout ou partie de nos données dans OSM.

Notre SI étant à jour, l'information que nous versons dans OSM aura la 
prétention d'être elle-même à jour en temps réel, même avec des changements 
fréquents.

Ce qui est dommage, c'est que la voirie, elle, lorsquelle effectue des travaux 
de rue, ne prend pas la peine de synchroser avec la communauté cette donnée 
publique.  Eux, font mal leur boulot vis à vis d'OSM.  Et, effectivement, les 
membres de la communauté ne suivent pas forcément au taquet les travaux!

> De mon point de vue, pour diffuser l'info sur un spectacle, il est
> préférable que ce soit dans un agenda culturel, plutôt que de
> signaler dans une base de données géographique là où on a mis des
> affiches pour signaler qu'il y a un spectacle... à un autre endroit.
> 
> Pour ça, il y a un projet plus adapté... OpenEventDatabase ;)

Pour bien comprendre, cela voudrait dire que les tags contact, page Facebook et 
autres URL de cette pizzeria n'ont rien à faire sur OSM, mais devraient plutôt 
être «référencées» uniquement par Google, Facebook et autres Pages Jaunes? 


contact:facebookhttps://www.facebook.com/Pizza-Tradition-526470680769739
contact:phone   +33 240202302
contact:website http://www.pizzatradition.fr

Et si on pousse plus ploin, que toute information hors sémantique 
cartographique n'a rien à faire dans OSM?

En plus, c'est une vraie question! ;)

Jean-Martial

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

[Talk-GB] Scalford Mapping Meeting tomorrow

[SK53]

Just an update about tomorrow's meeting in Scalford:

Meeting time is 10:30 in the car park of the Kings Arms
(not Red Lion as I inadvertently
stated originally). A (fairly current state of unmapped paths in the
neighbourhood can be seen on umap
.
I'll aslo try and have some printed/laminated maps with me.

Dudley has already reserved the obvious route to Holwell & back, but there
are at least 3 other alternatives towards Goadby Markwood and Waltham.

The pub opens at 12 and is unlikely to be busy. I will warn them to expect
4-6 of us.

We aim to join together for lunch from 12:45-14:00. Some chosen morning
routes are longer than others.

Waltham is the obvious target for additional mapping after lunch, but the
little network of paths to the W of Holwell are unlikely to be covered by
Dudley. There are also many shortish loops available between Scalford and
Long Clawson.

This area is I think very much the least touched area of Leicestershire.
The county as a whole suffers from relatively few paths with marked
designations (~ 27% of all footpaths by length), but a reasonable
proportion of paths are on OSM (60-65).

Regards,

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

Re: [OSM-talk-fr] Nouvelles bornes Trilib'

[Frédéric Rodrigo]

Je me disais justement que la même bidouille devait être possible. J'ai 
testé. Le résultat est un peu mieux que ce à quoi je m’attendais


J'ai pris tous les nodes de ways highway d'une commune et j'ai calculé 
un itinéraire pour tous les visiter.


http://umap.openstreetmap.fr/fr/map/carte-sans-nom_120855#14/44.5371/-0.3864

Il y quelque trous (gérable à la main), mais pas vraiment de demi tours.

C'est calculé avec Mapotempo en utilisant derrière OSRM et Vroom : 2h54, 
107 km



Frédéric.



Le 12/01/2017 à 14:54, Julien Coupey a écrit :

Re,

Si je comprends ton usage, le respect des sens uniques est important 
(vélo, voiture) mais pas forcément le sens de parcours des chemins 
pour lesquels il y a le choix ? En particulier tu n'a pas forcément 
besoin de passer dans les deux sens sur les chemins qui le permettent ?


Si c'est bien le cas, il y a peut-être un bricolage à tenter pour 
faire quelque chose sans rien développer. Mettons que tu veuilles 
prendre une photo tous les x mètres. Tu transformes alors ton problème 
en TSP en disant que tu souhaites visiter un paquet de nœuds par 
chemin (voire peut-être tous les nœuds de chaque chemin). On peut 
penser qu'une solution raisonnable à ce problème te fera parcourir les 
chemins en une seule fois dans la plupart des cas. Limitations :


- sans garantie d'absence de demi-tour au milieu en fonction de 
l'espacement des nœuds OSM)

- explosion de la taille du TSP (peut-être gérable quand même)
- c'est clairement une façon un peu moche de chercher quelque chose 
d'utilisable sans résoudre le problème initial ;-)


Si tu veux tenter quelque chose dans ce goût-là, n'hésite pas à me 
contacter en direct, je serais curieux de voir si ça peut donner 
quelque chose d'exploitable.


À+
Julien

Le 12/01/2017 à 14:05, Stéphane Péneau a écrit :

Le 11/01/2017 à 17:14, Julien Coupey a écrit :

Salut

Les problèmes de tournées consistent à passer par tous les nœuds d'un
certain graphe (avec éventuellement des contraintes additionnelles).
La nature du problème du postier chinois est différente puisqu'il
s'agit de visiter tous les arcs d'un graphe, donc malheureusement la
réponse à ta question est non. ;-)

Concrètement, si le sens de visite des chemins n'a pas d'importance et
s'il n'y a pas à tenir compte de sens uniques (par exemple à pied),
alors le graphe est non orienté et il existe des méthodes
réalistes/efficaces en temps de calcul pour trouver la solution 
optimale.

Par contre, si tu dois tenir compte des sens uniques et/ou si le sens
de visite a de l'importance (par exemple tu veux passer dans les rues
une fois dans chaque sens), alors là le problème se complique 
nettement !


À +
Julien


C'est dommage, et mon usage potentiel (passer partout, à vélo ou en
voiture pour prendre des photos) rentre dans le cas des situations qui
sont plus compliquées. (gestion des sens unique, gros gros malus sur les
demi-tour, etc..)

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




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

Re: [OSM-talk-fr] Adresses... (encore)

[Christian Quest]

Un numéro d'adresse est à voir plutôt comme un repère ordonné le long d'une
voie... ensuite il peut se passer plein de choses derrière: N parcelles, M
bâtiments qui peuvent en plus être liés à d'autres adresses (accès
multiples).

Pour la BAN on a discuté aussi très longuement de tout ça et le consensus
est resté sur le point de passage du domaine public au domaine privé.

Le souci avec le raisonnement qui aboutit au bâtiment, c'est qu'on saute
l'étape parcelle car elle est absente d'OSM. Elle fait en général le lien.


Le 13 janvier 2017 à 16:10, Nicolas Moyroud  a écrit :

>
> Cette discussion sera fin tant que tu n'auras pas conceptualisé l'adresse
>> autrement que penser qu'elle se rapporte obligatoirement à un bâtiment.
>>
> Pas forcément un bâtiment mais en tout cas l'adresse se rapporte à quelque
> chose. Et un point seul dans le vide ne rapporte à rien à part lui-même
> (sauf si tu le mets dans une relation comme je le disais précédemment). Et
> je pense également que cette discussion sera sans fin tant que certains
> n'auront pas conceptualisé ça.
> Je prends un exemple : tu as 4 entrées rapprochées au fond d'une impasse
> tu mets tes 4 numéros d'adresse les uns à côté des autres. Tu ne sais plus
> à quel objets se rapportent chacune des adresses (je dis objet
> volontairement pour que tu y mette ce que tu veux dans objet : bâtiment,
> parcelle).
> Donc c'est bien de mettre un numéro d'adresse tout seul, ça sert dans
> certains cas, mais il y a une perte d'informations et c'est dommage.
>
> Nicolas
>
> ___
> 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-fr] Adresses... (encore)

[Nicolas Moyroud]

Cette discussion sera fin tant que tu n'auras pas conceptualisé 
l'adresse autrement que penser qu'elle se rapporte obligatoirement à 
un bâtiment.
Pas forcément un bâtiment mais en tout cas l'adresse se rapporte à 
quelque chose. Et un point seul dans le vide ne rapporte à rien à part 
lui-même (sauf si tu le mets dans une relation comme je le disais 
précédemment). Et je pense également que cette discussion sera sans fin 
tant que certains n'auront pas conceptualisé ça.
Je prends un exemple : tu as 4 entrées rapprochées au fond d'une impasse 
tu mets tes 4 numéros d'adresse les uns à côté des autres. Tu ne sais 
plus à quel objets se rapportent chacune des adresses (je dis objet 
volontairement pour que tu y mette ce que tu veux dans objet : bâtiment, 
parcelle).
Donc c'est bien de mettre un numéro d'adresse tout seul, ça sert dans 
certains cas, mais il y a une perte d'informations et c'est dommage.


Nicolas

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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Christian Quest]

Le 13 janvier 2017 à 13:04, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM <
jean-mart...@zitcom.fr> a écrit :

>
> Effectivement, les données sur la situation des panneaux d'affichage libre
> n'est un secret pour personne (quoi quand on voit la difficulté de
> libération de ces données - au sens des données publiques ouvertes, parfois
> on se demande).
>
> Aussi, libre à chacun d'y afficher ce qu'il veut (c'est l'une des
> activités principales de ZIT.COM).
>
> Mais mon questionnement n'est pas là.
>
> Nous, nous faisons de l'affichage culturel: nous prenons les affiches de
> salles de spectacles (entre autres) et allons les placarder.
>
> Nous arpentons le terrain au quotidien et mettons à jour notre
> cartographie.  L'idée est de verser ces mise à jour dans OSM.
>
> Parmis les mises à jour, il y a par exemple que tel panneau d'affichage
> est HS, ou que pendant les élections municipales tel autre a été déplacé
> ici ou là.  Ça c'est le niveau primaire.
>
> Le deuxième niveau, et c'est là que l'éthique m'interpelle, c'est de
> modifier les champs du panneau, en temps réel (depuis notre SI) pour dire
> que sur ce panneau il y a telle affiche, de tel spectacle, avec les détails
> qui vont bien (type de spectacle, date, producteur, URL, billetterie en
> ligne, etc.)
>
> Car, après tout, en quoi ça diffère techniquement que de mettre à jour les
> informations d'ouverture d'un shop ou de mettre l'URL du site Web, la page
> Facebook, etc. du commerçant comme ici pour cette pizzeria <
> https://www.openstreetmap.org/node/4239161089>.
>
> Et bien c'est dans ce sens que je pose la question.  Comment, bien sûr
> (tel ou tel tag, tel ou tel point, etc.)?  Mais surtout, pourquoi ou
> pourquoi pas, selon les fondements du projet OSM?  (Ce que j'ignore encore,
> ne faisant pas partie de la communauté...)
>
> Alors, contribuer à l'«affichage public», poui, mais jusqu'où?
>

Indiquer qu'il y a un panneau d'affichage public c'est fournir une
information neutre et stable dans le temps.
Indiquer ce qui se trouve sur ce panneau, c'est déjà moins neutre et c'est
aussi très (trop) changeant pour que l'info soit fiable quand on la
consulte.

C'est la limite d'OSM par rapport à de l'info très dynamique. On se pose le
même genre de question pour des routes coupées par des travaux. Si ça dure
vraiment (plusieurs semaines, mois, impact important), oui, on peut
l'indiquer dans OSM.

De mon point de vue, pour diffuser l'info sur un spectacle, il est
préférable que ce soit dans un agenda culturel, plutôt que de signaler dans
une base de données géographique là où on a mis des affiches pour signaler
qu'il y a un spectacle... à un autre endroit.

Pour ça, il y a un projet plus adapté... OpenEventDatabase ;)


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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Christian Rogel]

Le 13 janv. 2017 à 13:22, Nicolas Moyroud  a écrit :
>> je suis personnellement pour le partage des connaissance (mais réticent au 
>> partage des données privées, genre piscines, voie d’accès sur les parcelles 
>> privées -surtout qu’elles ne sont pas forcément distingué dans les rendus…)
> Faux les voies d'accès privées si on leur affecte le bon tag access=private 
> sont clairement distinguées sur les rendus.

Pour les rues pavillonnaires, je place le point d'adresse selon la disposition 
des lieux :
1 À l'entrée de l'allée privée si la maison est dans un axe perpendiculaire
2 À la fin de l'allée avant la cour ou le parking, si la ou les maisons se 
retrouvent derrière les autres numéros de la rue.
Dans tous les cas, le routage mène à l'entrée de l'allée privée, la 
consultation de la carte ou, le cas échéant, l'affichage double ou triple 
apportant la précision utile.

Christian R.

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

Re: [Talk-it] probabile troll

[Stefano]

Il giorno 13 gennaio 2017 15:27, Andrea Musuruane  ha
scritto:

> Ciao,
> C'è un modo per recuperare tutti i commenti ai changeset che ho fatto?
> Perché ne commento sempre tanti, ma di risposte ne ricevo veramente poche...
>
>
http://resultmaps.neis-one.org/osm-discussion-comments?uid=90379



> Grazie.
>
> Ciao,
>
> Andrea
>

Ciao,
Stefano


>
>
> 2017-01-13 15:24 GMT+01:00 Volker Schmidt :
>
>> Nessuna risposta. Ho eliminato i due nodi.
>>
>> 2017-01-13 15:07 GMT+01:00 Davide Sandona' :
>>
>>> mai ricevuto risposta. secondo me puoi fare il reverse di entrambi i
>>> changeset
>>>
>>> Davide.
>>>
>>> Il giorno 13 gennaio 2017 14:23, Marco  ha
>>> scritto:
>>>
 Ritorniamo al problema principale della discussione; rimangono ancora,
 in posizioni poco verosimili, i due nodi da lui creati. Qualcuno ha avuto
 risposta dal mappatore in questione?
 Il nodo di Piazza Duomo a Vicenza mi sembra senza senso, l'altro
 potrebbe anche essere spostato e non cancellato, a patto di capire dove
 vada messo.
 Posso anche offrirmi io di sistemare, mi sembra un lavoro da 2 minuti.
 Attendo il vostro parere

 Ciao
 Marco


 ___
 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] probabile troll

[Andrea Musuruane]

Ciao,
C'è un modo per recuperare tutti i commenti ai changeset che ho fatto?
Perché ne commento sempre tanti, ma di risposte ne ricevo veramente poche...

Grazie.

Ciao,

Andrea


2017-01-13 15:24 GMT+01:00 Volker Schmidt :

> Nessuna risposta. Ho eliminato i due nodi.
>
> 2017-01-13 15:07 GMT+01:00 Davide Sandona' :
>
>> mai ricevuto risposta. secondo me puoi fare il reverse di entrambi i
>> changeset
>>
>> Davide.
>>
>> Il giorno 13 gennaio 2017 14:23, Marco  ha
>> scritto:
>>
>>> Ritorniamo al problema principale della discussione; rimangono ancora,
>>> in posizioni poco verosimili, i due nodi da lui creati. Qualcuno ha avuto
>>> risposta dal mappatore in questione?
>>> Il nodo di Piazza Duomo a Vicenza mi sembra senza senso, l'altro
>>> potrebbe anche essere spostato e non cancellato, a patto di capire dove
>>> vada messo.
>>> Posso anche offrirmi io di sistemare, mi sembra un lavoro da 2 minuti.
>>> Attendo il vostro parere
>>>
>>> Ciao
>>> Marco
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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-it] probabile troll

[Volker Schmidt]

Nessuna risposta. Ho eliminato i due nodi.

2017-01-13 15:07 GMT+01:00 Davide Sandona' :

> mai ricevuto risposta. secondo me puoi fare il reverse di entrambi i
> changeset
>
> Davide.
>
> Il giorno 13 gennaio 2017 14:23, Marco  ha scritto:
>
>> Ritorniamo al problema principale della discussione; rimangono ancora, in
>> posizioni poco verosimili, i due nodi da lui creati. Qualcuno ha avuto
>> risposta dal mappatore in questione?
>> Il nodo di Piazza Duomo a Vicenza mi sembra senza senso, l'altro potrebbe
>> anche essere spostato e non cancellato, a patto di capire dove vada messo.
>> Posso anche offrirmi io di sistemare, mi sembra un lavoro da 2 minuti.
>> Attendo il vostro parere
>>
>> Ciao
>> Marco
>>
>>
>> ___
>> 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
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Adresses... (encore)

[Romain MEHUT]

Nicolas, je poursuis sur ce fil

Mais qui a dit que le numéro d'adresse devait être placé sur le point
> d'accès ? On ne travaille pas exclusivement pour les usages des postiers
> que je sache !
> Si tu mets un numéro d'adresse sur un noeud flottant qui n'est raccroché à
> rien d'autre, il faudrait à minima le mettre dans une relation qui contient
> également le ou les bâtiments concernés. Sinon impossible de savoir à quoi
> se rapporte ton numéro d'adresse et il ne sert plus qu'à une seule chose :
> savoir où se trouve le portail ou la boîte aux lettres. Ce qui à mon sens
> n'est pas l'intérêt principal d'un numéro d'adresse dans OSM, mais le seul
> intérêt de la poste...
>

Pourquoi parles-tu des postiers ? Quand je souhaite me rendre à une
adresse, je ne cherche pas nécessairement à me rendre à un bâtiment mais à
un point d'accès menant éventuellement à un bâtiment et également à tout ce
qui s'y attache.

Cette discussion sera fin tant que tu n'auras pas conceptualisé l'adresse
autrement que penser qu'elle se rapporte obligatoirement à un bâtiment.

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

Re: [Talk-it] probabile troll

[Davide Sandona']

mai ricevuto risposta. secondo me puoi fare il reverse di entrambi i
changeset

Davide.

Il giorno 13 gennaio 2017 14:23, Marco  ha scritto:

> Ritorniamo al problema principale della discussione; rimangono ancora, in
> posizioni poco verosimili, i due nodi da lui creati. Qualcuno ha avuto
> risposta dal mappatore in questione?
> Il nodo di Piazza Duomo a Vicenza mi sembra senza senso, l'altro potrebbe
> anche essere spostato e non cancellato, a patto di capire dove vada messo.
> Posso anche offrirmi io di sistemare, mi sembra un lavoro da 2 minuti.
> Attendo il vostro parere
>
> Ciao
> Marco
>
>
> ___
> 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-it] OSMit2017 a Genova 8-11 febbraio in FOSS4G

[Alessandro Palmas]

Salve lista,
a ieri sera erano 47 le proposte di interventi a FOSS4G-IT
Ricordo che c'è tempo sino a stasera per compilare la form per le 
proposte d'intervento orale o poster. Per la sessione poster ricordo che 
è un formato A1 verticale e che dovrebbe perferibilmente avere in testa 
i loghi dell'evento (fate uno screenshot della testa della pagina 
http://www.dicca.unige.it/geomatica/foss4git_2017/ e siete a posto).


Stamane ho aggiunto una mia sessione poster sugli strumenti di 
monitoraggio e controllo qualità. A tal riguardo vi chiedo se siete a 
conoscenza di qualche sito o tool particolare a parte i più famosi 
(osmose, OsmInspector, whodidit e gli strumenti di Pascal Neiss). Mi 
pare rilevante far conoscere sia ad alcuni OSMer che al pubblico tutti 
gli strumenti disponibili per le attività di monitoraggio e ricerca di 
potenziali errori.


Alessandro Ale_Zena_IT

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

Re: [Talk-it] probabile troll

[Marco]

Ritorniamo al problema principale della discussione; rimangono ancora, 
in posizioni poco verosimili, i due nodi da lui creati. Qualcuno ha 
avuto risposta dal mappatore in questione?
Il nodo di Piazza Duomo a Vicenza mi sembra senza senso, l'altro 
potrebbe anche essere spostato e non cancellato, a patto di capire dove 
vada messo.

Posso anche offrirmi io di sistemare, mi sembra un lavoro da 2 minuti.
Attendo il vostro parere

Ciao
Marco

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

[OSM-talk-be] (no subject)

[Marc Gemis]

Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat
om te lezen :-)

Jasper,

De oorspronkelijke betekenis van landuse=forest was een bosgebied
waarvan het hout gekapt wordt voor industriële doeleinden (bosbouw).
Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel
niet elk onderhouden bos echt voor bosbouw is.

Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor
een groepje bomen.

Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar
met grote struiken via luchtfoto's als landuse=forest worden gemapped.

Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje
grond dat jij aangeeft. scrub wordt ook wel als struikgewas of
kreupelhout vertaalt (google translate). Dus dat pas wel.

Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest ,
toch als er meer struiken zijn dan bomen. Maar wat als er dan toch wat
onderhoud aan te pas komt ?

Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het
zij zo. Als er genoeg landcover tags gebruikt worden, gaan ze die ook
wel tonen.

Over het verschil tussen landcover=grass en landuse=grass
Landuse zou het gebruik van het land moeten aangeven. Hier wonen
mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
landbouw of veeteelt gedaan, enz.
Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass
niet echt juist is, misschien enkel voor gebieden waar graszodes
geteeld worden. Maar omdat het op de kaart getoond wordt, zie je
landuse=grass overal verschijnen. (ipv het correctere landcover=grass)

Landcover slaat op wat je op de grond vindt.

Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
polygonen behoren:
eentje met een landuse tag een eentje met een landcover tag. De ene
geeft de bestemming aan, de andere wat je op de grond vindt. En dan
kan je ook nog in sommige gevallen het type recreatie (leisure) of
faciliteiten (amenity), etc. daarboven op gaan mappen.

Dus voor een park
- leisure=park (doen we nu al)
- landuse=xxx (nog te definiëren)
- dan voor verschillende delen landcover=trees of grass of bushes of
sand, rocks, etc.
-
Momenteel mappen we meestal enkel leisure=park, en misschien al eens
een landuse=grass of forest.


Bij een woning met tuin
- landuse=residential
- landcover (zoals bij park) voor de tuin, misschien voor oprit, de
plek van het huis, terras, e.d. nog andere landcovers
Dus hier geen landuse=forest om de tuin aan te duiden. Er is geen
bosbouw, er is ook geen bos om te recreëren, dus waarom landuse=forest
? Dat is taggen voor de renderer [1].

Dat is volgens mij het doel van de landcover, om los van het gebruik
bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest
terug voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt
worden voor bossen met een recreatieve of natuurbeschermende
bestemming.

Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg
nagedacht over landuses.

Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)

m

p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je
goed moet nadenken over de betekenis van een woord voor je het kan
mappen. Wat is een park ? Wat is een tuin ? (of iets heel anders: )
wat is een parking/parkeerterrein ? (dit is niet hetzelfde als een
parkeerplaats)
p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had
me er vroeger nooit zo bezig gehouden met het mappen van
landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te
lezen over het thema, vragen op mailing lists te volgen,  en dan ben
je nog niet wijzer.
p.s. Joost, je schreef ooit dat het gemakkelijker wordt als je meer
weet over OSM, maar dat is niet waar, zie de vorige p.s. :-)

[1] toch in de bewoonde wereld, op Antartica is landuse misschien niet nodig
[2] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

2017-01-13 13:24 GMT+01:00 Jasper Michels :
> De discussie ook gelezen.
> Wat voor mij echter niet duidelijk is.
> Hoe tag je niet onderhoud bermen met struiken en enkele kleine boompjes
> (struiken die tot bomen uitgroeien) langs de straat.
> Zoals je nogal veel ziet langs grote wegen, of op het platteland.
> https://www.openstreetmap.org/#map=18/50.84018/3.60314
>
> Momenteel gebruik ik hier: Landuse=forest
> Maar volgens de wiki is dit enkel voor echte bossen.
> Dienen we dan landcover=bushes te gebruiken?
>
> de tag garden vindt ik hiervoor echt niet kunnen.
> Een garden beschouw ik een aangelegd stuk grond, dat 

Re: [OSM-talk-be] Groen in de steden

[Jasper Michels]

De discussie ook gelezen.
Wat voor mij echter niet duidelijk is.
Hoe tag je niet onderhoud bermen met struiken en enkele kleine boompjes
(struiken die tot bomen uitgroeien) langs de straat.
Zoals je nogal veel ziet langs grote wegen, of op het platteland.
https://www.openstreetmap.org/#map=18/50.84018/3.60314

Momenteel gebruik ik hier: Landuse=forest
Maar volgens de wiki is dit enkel voor echte bossen.
Dienen we dan landcover=bushes te gebruiken?

de tag garden vindt ik hiervoor echt niet kunnen.
Een garden beschouw ik een aangelegd stuk grond, dat regelmatig onderhouden
wordt.

Aan de discussie tussen landcover en landuse (bijvoorbeeld voor gras)
geraak ik al helemaal niet uit.
Persoonlijk heb ik nogal graag dat wat ik map effectief een nut heeft, en
dus daadwerkelijk op de kaart gerenderd wordt.

Indien je een golfterrein hebt met veel bomen op.
Ben ik dan juist dat ik de bomen als landuse: forest tag?
Zie hieronder voorbeeld:
https://www.openstreetmap.org/#map=15/50.8221/3.5553

Reeds bedankt voor de feedback,

Kbenktekik


Op 13 januari 2017 om 12:38 schreef Marc Gemis :

> Ik denk dat we het nog wat ruimer mogen zien: elk stukje grond met
> bloemen, planten, struiken, gras en/of bomen dat te klein is voor een
> park of tuin.
>
> Sommigen mappen zoiets wel als tuin, anderen zien het als barrier,
> weer anderen als landuse=highway (maakt deel uit van de straat), enz.
>
> De wikipedia definitie van Village Green [1] en die van OSM slaan voor
> mij niet op die kleine stukjes groen. Maar Marc Zoutendijk heeft er in
> de UK gevonden die wel zo klein zijn.
>
> Waar ik village_green had gebruikt heb ik gisteren gewijzigd. Indien
> er een pad doorliep is het een park geworden (er is geen minimum
> grootte voor een park), eentje is een recreation area geworden (er
> stonden voetbal doelen op voor de jeugd). de rest door landcover. Die
> zie je misschien niet op de kaart, maar dat geeft tenminste correct
> weer dat er gras, struiken, etc. staan zonder een uitspraak te doen
> over het gebruik (wat in landuse of leisure moet komen).
>
> Je hebt gelijk met de vertalingsproblemen, volgens google translate:
>
> perk = bed
> plantsoen = plantation (maar ook voor plantage, kwekerij in gebruik)
> aanplant = planting
> dorpsplein = village green (hier het Engelse woord opgezocht)
>
> m.
>
> [1] https://en.wikipedia.org/wiki/Village_green
>
> 2017-01-13 9:38 GMT+01:00 Santens Seppe :
> > Ik heb de discussie enkel diagonaal gelezen. Als ik het goed begrijp,
> zou er eigenlijk een tag moeten zijn die overeenkomt met het Nederlandse
> woord "perk" (Vandale: tuinvak met bloemen of planten). Ik denk wel dat het
> moeilijk is om daar in het Engels een goed equivalent voor te vinden.
> >
> > Seppe
> >
> > -Oorspronkelijk bericht-
> > Van: Marc Gemis [mailto:marc.ge...@gmail.com]
> > Verzonden: woensdag 11 januari 2017 17:28
> > Aan: OpenStreetMap Belgium
> > Onderwerp: [OSM-talk-be] Groen in de steden
> >
> > Op het Nederlandse forum loopt een interessante discussie over het
> mappen van groen in de steden & gemeenten:
> > https://forum.openstreetmap.org/viewtopic.php?id=56899
> >
> > Deze discussie loopt in parallel op de tagging mailing list.
> >
> > m.
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Nicolas Moyroud]

je suis personnellement pour le partage des connaissance (mais 
réticent au partage des données privées, genre piscines, voie d’accès 
sur les parcelles privées -surtout qu’elles ne sont pas forcément 
distingué dans les rendus…)
Faux les voies d'accès privées si on leur affecte le bon tag 
access=private sont clairement distinguées sur les rendus.
Pour les piscines, je n'arrive pas à comprendre la logique qui est 
derrière. Ce n'est pas plus privé qu'un bâtiment qui représente une 
maison. Cette donnée est disponible sur la cadastre également. Vu que 
l'on s'autorise à intégrer les bâtiments du cadastre dans OSM, il n'y 
absolument aucune raison valable que l'on ne fasse pas pareil avec les 
piscines, en prenant bien entendu soin d'ajouter le tag access=private 
dessus.
C'est marrant cette réticence sur les piscines en France. Je me demande 
d'où ça peut bien venir... :-P


Nicolas


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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Tyndare]

Le 13 janvier 2017 12:00:51 GMT+01:00, Nicolas Moyroud  a 
écrit :
>
>> En milieu urbain, ce point d'accès sera souvent sur le bâtiment 
>> lui-même mais il suffit que le(s) bâtiment(s) soit en retrait de la 
>> voirie, le point d'accès et donc l'adresse seront alors indépendants 
>> du (des) bâtiment(s).
>Mais qui a dit que le numéro d'adresse devait être placé sur le point 
>d'accès ? On ne travaille pas exclusivement pour les usages des
>postiers 
>que je sache !
>Si tu mets un numéro d'adresse sur un noeud flottant qui n'est
>raccroché 
>à rien d'autre, il faudrait à minima le mettre dans une relation qui 
>contient également le ou les bâtiments concernés. Sinon impossible de 
>savoir à quoi se rapporte ton numéro d'adresse et il ne sert plus qu'à 
>une seule chose : savoir où se trouve le portail ou la boîte aux 
>lettres. Ce qui à mon sens n'est pas l'intérêt principal d'un numéro 
>d'adresse dans OSM, mais le seul intérêt de la poste...

A titre perso, ce que j'attends d'une adresse c'est que mon GPS soit capable de 
m'y amener. En l'indiquant systématiquement sur les bâtiments il y a énormément 
de cas où les logiciels de routage vont essayer d'y arriver par le mauvais 
côte, et donc être bien pire que l'absence de numéro d'adresse qui nous 
amènerait au moins dans la bonne rue.

L'adresse, pour qu'elle soit utile, doit être cohérente avec les autres 
éléments cartographiés pour permettre le routage. 

Les logiciels de routage évitent les passages privés, donc ça me paraît logique 
l'indiquer l'adresse  sur la frontière de la zone privée adressée.


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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

>> Intuitivement, je vois un «danger» au développement de l'affichage
>> libre: OSM risque de devenir un support pour les régies
>> publicitaires, non?
>> 
>> OK, ça reste à la marge (quelques panneaux et annonces ici ou là pour
>> la promotion de tel ou tel spectacle ou tel ou tel candidat à
>> l'élection présidentielle, face à des milliards d'objets de carto
>> pure).
> 
> je suis personnellement pour le partage des connaissance (mais
> réticent au partage des données privées, genre piscines, voie
> d’accès sur les parcelles privées -surtout qu’elles ne sont pas
> forcément distingué dans les rendus…)
> et il me semble que c’est une des dimension de projets comme OSM
>
> concernant l’affichage libre / affichage associatif, c’est un
> équipement destiné au publique (pour voir ou montrer) il me semble
> d’autant plus souhaitable de facilité son accès
> d’ailleurs beaucoup de municipalités diffusent leurs emplacement sur
> leur site internet
> il appartient ensuite à chacun d’en respecter les règle et au équipes
> municipales de les faire respecter
> de plus les spectacle et autre sont souvant les mieux informés de
> leurs emplacement (étant justement en recherche régulière de zone
> d’affichage) et dans la pratique un tel affichage s’il reste modéré
> est souvent toléré (faisant partie de la vie et culture locale)
> la municipalité a d’ailleurs des moyens de pression sur les
> potentiels resquilleurs (qui sont facilement identifiables et
> dépendent souvent d’autorisation et subvention pour leurs activités)

Effectivement, les données sur la situation des panneaux d'affichage libre 
n'est un secret pour personne (quoi quand on voit la difficulté de libération 
de ces données - au sens des données publiques ouvertes, parfois on se demande).

Aussi, libre à chacun d'y afficher ce qu'il veut (c'est l'une des activités 
principales de ZIT.COM).

Mais mon questionnement n'est pas là.

Nous, nous faisons de l'affichage culturel: nous prenons les affiches de salles 
de spectacles (entre autres) et allons les placarder.

Nous arpentons le terrain au quotidien et mettons à jour notre cartographie.  
L'idée est de verser ces mise à jour dans OSM.

Parmis les mises à jour, il y a par exemple que tel panneau d'affichage est HS, 
ou que pendant les élections municipales tel autre a été déplacé ici ou là.  Ça 
c'est le niveau primaire.

Le deuxième niveau, et c'est là que l'éthique m'interpelle, c'est de modifier 
les champs du panneau, en temps réel (depuis notre SI) pour dire que sur ce 
panneau il y a telle affiche, de tel spectacle, avec les détails qui vont bien 
(type de spectacle, date, producteur, URL, billetterie en ligne, etc.)

Car, après tout, en quoi ça diffère techniquement que de mettre à jour les 
informations d'ouverture d'un shop ou de mettre l'URL du site Web, la page 
Facebook, etc. du commerçant comme ici pour cette pizzeria 
.

Et bien c'est dans ce sens que je pose la question.  Comment, bien sûr (tel ou 
tel tag, tel ou tel point, etc.)?  Mais surtout, pourquoi ou pourquoi pas, 
selon les fondements du projet OSM?  (Ce que j'ignore encore, ne faisant pas 
partie de la communauté...)

Alors, contribuer à l'«affichage public», poui, mais jusqu'où?

Jean-Martial

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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Erwan Salomon]

> Le 13 janv. 2017 à 11:04, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM 
>  a écrit :
> 
> Intuitivement, je vois un «danger» au développement de l'affichage libre: OSM 
> risque de devenir un support pour les régies publicitaires, non?
> 
> OK, ça reste à la marge (quelques panneaux et annonces ici ou là pour la 
> promotion de tel ou tel spectacle ou tel ou tel candidat à l'élection 
> présidentielle, face à des milliards d'objets de carto pure).

je suis personnellement pour le partage des connaissance (mais réticent au 
partage des données privées, genre piscines, voie d’accès sur les parcelles 
privées -surtout qu’elles ne sont pas forcément distingué dans les rendus…)  
et il me semble que c’est une des dimension de projets comme OSM
concernant l’affichage libre / affichage associatif, c’est un équipement 
destiné au publique (pour voir ou montrer) il me semble d’autant plus 
souhaitable de facilité son accès
d’ailleurs beaucoup de municipalités diffusent leurs emplacement sur leur site 
internet
il appartient ensuite à chacun d’en respecter les règle et au équipes 
municipales de les faire respecter
de plus les spectacle et autre sont souvant les mieux informés de leurs 
emplacement (étant justement en recherche régulière de zone d’affichage) et 
dans la pratique un tel affichage s’il reste modéré est souvent toléré (faisant 
partie de la vie et culture locale)
la municipalité a d’ailleurs des moyens de pression sur les potentiels 
resquilleurs (qui sont facilement identifiables et dépendent souvent 
d’autorisation et subvention pour leurs activités)___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-br] duplicidade de projetos

[Jucá Costa]

Olá a todos.

Estas duas listas foram criadas a partir de dois métodos diferentes 
processamento de geodados, como descrito em cada uma das páginas. Não é que uma 
seja a correta/atualizada e a outra não — o conteúdo de cada uma é 
conceitualmente diferente. Há elementos que só estão presentes em uma lista e 
outros que só estão presentes na outra. Além disso, uma lista relações e a 
outra lista nós .
De fato há algumas repetições, mas acho que, se é que alguma ação deva ser 
tomada, deveríamos apenas remover as repetições na página das cidades, deixando 
esta apenas com as cidades que não são sede de seu município. Aproveito para 
deixar também um pedido que, quando discutirem conteúdo de páginas da wiki na 
lista de e-mail, deixem um aviso na página de discussão da página em questão, 
para que os seus editores, parte interessada, sejam notificados. Abraços.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Nicolas Moyroud]

En milieu urbain, ce point d'accès sera souvent sur le bâtiment 
lui-même mais il suffit que le(s) bâtiment(s) soit en retrait de la 
voirie, le point d'accès et donc l'adresse seront alors indépendants 
du (des) bâtiment(s).
Mais qui a dit que le numéro d'adresse devait être placé sur le point 
d'accès ? On ne travaille pas exclusivement pour les usages des postiers 
que je sache !
Si tu mets un numéro d'adresse sur un noeud flottant qui n'est raccroché 
à rien d'autre, il faudrait à minima le mettre dans une relation qui 
contient également le ou les bâtiments concernés. Sinon impossible de 
savoir à quoi se rapporte ton numéro d'adresse et il ne sert plus qu'à 
une seule chose : savoir où se trouve le portail ou la boîte aux 
lettres. Ce qui à mon sens n'est pas l'intérêt principal d'un numéro 
d'adresse dans OSM, mais le seul intérêt de la poste...


Nicolas

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

Re: [OSM-talk-fr] Adresses... (encore)

[Christian Quest]

Le 13 janvier 2017 à 11:20, Romain MEHUT  a écrit :

> Pour te paraphraser, le numéro d'adresse pour moi c'est un élément qui
> caractérise avant tout un élément (objet) en tant que tel qui ne se
> rapporte pas qu'à un ou plusieurs bâtiments mais aussi parfois à un
> ensemble plus vaste donc je figure cet objet au point d'accès de cet
> ensemble. En milieu urbain, ce point d'accès sera souvent sur le bâtiment
> lui-même mais il suffit que le(s) bâtiment(s) soit en retrait de la voirie,
> le point d'accès et donc l'adresse seront alors indépendants du (des)
> bâtiment(s).
>


Sujet maintes fois débattu... et on n'a jamais pu trancher !

Entre adresses, bâtiments et parcelles (donc les terrains) on des liens
N-N. L'adresse est donc bien quelque chose de différent d'un bâtiment pour
ça que moi aussi je préfère sa version ponctuelle avec une vue "point
d'accès" entre la domaine public et le domaine privé où là on peut avoir
plusieurs bâtiments plusieurs parcelles ou autre...


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

Re: [Talk-GB] the steepest residential street in England

[Jez Nicholson]

That's pretty steep.

I'm also thinking of Keere Street, Lewes https://goo.gl/maps/uBRWoaSXx122 but
i'm sure that i've seen some ridiculous ones in tiny Cornish villages

On Fri, 13 Jan 2017 at 10:19 John Sturdy  wrote:

> North Lane in Bath (
> http://www.openstreetmap.org/way/2955824#map=19/51.37754/-2.33364) is
> very steep, but only side entrances to houses open onto it, so I'm not sure
> whether it counts fully as residential.
>
> __John
>
> On Fri, Jan 13, 2017 at 1:42 AM, Dave F 
> wrote:
>
>
> On 12/01/2017 01:02, Robert Norris wrote:
>
> Ffordd_Pen_Llech is steep but it's one way (down), so if you're looking
> for challenge to go up it on your bicycle you have to do so illegally.
>
> Apparently Vale Street (http://www.openstreetmap.org/way/32024547) in
> Bristol is meant to be very steep, but I don't know the incline. (Doesn't
> seem to have incline posted looking at GSV. DaveF: Was this the road you
> were thinking of or something in Bath?)
>
>
> Just outside:
>
> https://www.google.co.uk/maps/@51.3977312,-2.2940096,3a,88.4y,62.25h,61.15t/data=!3m4!1e1!3m2!1sedHvMRtPcF5jZw2uQdD4Hw!2e0
>
> It may not be the steepest, but it gives your calf muscles a good work
> out. That bend in the road is the real killer on a bike.
>
> DaveF
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Romain MEHUT]

Bonjour,

Le 13 janvier 2017 à 10:33, Nicolas Moyroud  a écrit :

Le numéro d'adresse pour moi c'est un élément qui caractérise avant tout
> l'habitation principale et pas le garage ou le pigeonnier donc je trouve
> qu'il est toujours pertinent de mettre le point sur le contour du bâtiment
> principal et je n'ai quasiment jamais eu à dévier de ce schéma.


Pour te paraphraser, le numéro d'adresse pour moi c'est un élément qui
caractérise avant tout un élément (objet) en tant que tel qui ne se
rapporte pas qu'à un ou plusieurs bâtiments mais aussi parfois à un
ensemble plus vaste donc je figure cet objet au point d'accès de cet
ensemble. En milieu urbain, ce point d'accès sera souvent sur le bâtiment
lui-même mais il suffit que le(s) bâtiment(s) soit en retrait de la voirie,
le point d'accès et donc l'adresse seront alors indépendants du (des)
bâtiment(s).

Romain


> Même si il y a de rares cas où déterminer quel est le bâtiment principal
> n'a pas été facile, avec les images aériennes j'ai quasiment toujours
> réussi à m'en sortir.
> Mais encore une fois tout cela n'engage que ma propre opinion et ma
> pratique personnelle du tagging OSM. :-)
>
> Nicolas
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] the steepest residential street in England

[John Sturdy]

North Lane in Bath (
http://www.openstreetmap.org/way/2955824#map=19/51.37754/-2.33364) is very
steep, but only side entrances to houses open onto it, so I'm not sure
whether it counts fully as residential.

__John

On Fri, Jan 13, 2017 at 1:42 AM, Dave F  wrote:

>
> On 12/01/2017 01:02, Robert Norris wrote:
>
>> Ffordd_Pen_Llech is steep but it's one way (down), so if you're looking
>> for challenge to go up it on your bicycle you have to do so illegally.
>>
>> Apparently Vale Street (http://www.openstreetmap.org/way/32024547) in
>> Bristol is meant to be very steep, but I don't know the incline. (Doesn't
>> seem to have incline posted looking at GSV. DaveF: Was this the road you
>> were thinking of or something in Bath?)
>>
>
> Just outside:
> https://www.google.co.uk/maps/@51.3977312,-2.2940096,3a,88.4
> y,62.25h,61.15t/data=!3m4!1e1!3m2!1sedHvMRtPcF5jZw2uQdD4Hw!2e0
>
> It may not be the steepest, but it gives your calf muscles a good work
> out. That bend in the road is the real killer on a bike.
>
> DaveF
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-es] Issue sobre OSM en el Github de Telegram

[Héctor Ochoa]

Está empezando a ponerse interesante esta discusión que empecé en el Github
de telegram-desktop sobre qué mapa sería mejor utilizar para mandar
ubicaciones en Telegram (obviamente me incliné por OSM).
Aquí el link por si deseáis aportar vuestra opinión:
https://github.com/telegramdesktop/tdesktop/issues/2787
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

Bonjour les copains!

(Je sens que nous commençons à être intimes, il est 9h, nous sommes vendredi, 
ce fil de discussion a enrichi ma semaine, alors permettez-moi de me lâcher ;)

> il y a 1-2 ans je me suis intéressé aux affichages libre, il n’y
> avait pas de convention
> après discussion sur le forum, sans trouver de consensus, j’ai adopté
> un ensemble tag qui me semblait la moins mauvaise
> après une absence de OSM je reviens et je découvre que ce type
> d’affichage est maintenant bien renseigné sur le wiki (je vais
> pouvoir reprendre tous mes anciens tags)
> 
> en tout cas je suis votre discussion avec grand intérêt, ça me permet
> moi aussi d’en apprendre sur le processus d’intégration

Intuitivement, je vois un «danger» au développement de l'affichage libre: OSM 
risque de devenir un support pour les régies publicitaires, non?

OK, ça reste à la marge (quelques panneaux et annonces ici ou là pour la 
promotion de tel ou tel spectacle ou tel ou tel candidat à l'élection 
présidentielle, face à des milliards d'objets de carto pure).

Par exemple, sur Wikipédia, c'est, entre autres, la «neutralité de point de 
vue» qui limite les articles promotionnels et la publicité déguisée 
.

Qu'en est-il sur OSM?  (J'ai pas fouillé, mais c'est votre avis 
pratico-pratique qui m'importe dans un premier temps.)

> J'ajoute pour le principe : KISS , Keep It Simple Stupid
> 
> On peut détailler à l'infini avec le système de tags d'OSM, mais il
> faut savoir commencer par des choses simples pour démarrer.
> Ajouter les commerces, leurs horaires d'ouverture, ça sera déjà une
> bonne première étape Compléter par les SIRET, ça permet un lien plus
> pérenne avec vos données.
> 
> Il faut apprendre à marcher avant de vouloir courir ;)

C'est vrai qu'il faut marcher avant de vouloir courir, notre corp nous le 
rappelle (ouille ça fait mal!).

Néanmoins, l'objet de mes interrogations est de savoir où ma boîte pourrait 
aller avec OSM: nous savons déjà, techniquement, marcher et courrir (maîtrise 
de notre activité, développement de notre SI, interconnexion avec d'autres 
systèmes par l'utilisation d'API, etc.)

Ce que je cherche ici, c'est bien de comprendre ce que nous pouvons partager 
ensemble (pas comment nous pouvons le partager, car il me semble qu'il y a ce 
qu'il faut).

> Le raccourci que je prendrai par contre dès le départ si vous
> envisagez de contribuer massivement et sur le long terme, c'est de
> démarrer directement avec l'éditeur JOSM et de bypasser iD (éditeur
> en ligne qui fonctionne dans votre navigateur).

Je vais explorer ça attentivement.

Jean-Martial

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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Nicolas Moyroud]

Cette solution "point du polygone" ne convient pas vraiment quand il y 
a une maison d'un côté et un garage de l'autre sur lequel est la bàl : 
il vaut mieux un point au niveau du portail entre les deux.
Qui a dit que la position du point devait forcément se trouver à 
l'endroit de la boîte aux lettres ou du portail ? On parle d'un numéro 
d'adresse de manière globale pas d'une position de boîte aux lettres ou 
de l'entrée d'un lieu d'habitation. Donc pour ça il vaudrait mieux 
utiliser les tags entrance=main ou barrier=gate (et inventer un tag pour 
indiquer une boîte aux lettres de réception du courrier).
Le numéro d'adresse pour moi c'est un élément qui caractérise avant tout 
l'habitation principale et pas le garage ou le pigeonnier donc je trouve 
qu'il est toujours pertinent de mettre le point sur le contour du 
bâtiment principal et je n'ai quasiment jamais eu à dévier de ce schéma. 
Même si il y a de rares cas où déterminer quel est le bâtiment principal 
n'a pas été facile, avec les images aériennes j'ai quasiment toujours 
réussi à m'en sortir.
Mais encore une fois tout cela n'engage que ma propre opinion et ma 
pratique personnelle du tagging OSM. :-)


Nicolas

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

[Talk-br] CNEFE

[Papibaquígrafo]

A minha sugestão sobre como consumir os dados do CNEFE no OSM seria criar (mais 
uma) camada de referência. Pensei num mapa interativo, mais ou menos assim:

http://umap.openstreetmap.fr/en/map/untitled-map_120703#19/-23.54619/-46.63194

O legal é que os estabelecimentos comercias costumam estar identificados no 
campo "nota", assim dá pra usar esse mapa pra procurar o número do banco do 
brasil, da loja de bijuterias, etc. (Não consegui trocar as bolas azuis pelo 
próprio número do prédio, mas deve ser possível) 
Como são gigabytes de dados, a gente provavelmente precisaria da nossa própria 
instância do umap (ou webapp similar). Eu posso colaborar com os dados que 
alimentarão o mapa, mas já adianto que pessoalmente não tenho conhecimento ou 
interesse em configurar um site desse tipo.

PS: Sim, isto seria muito diferente de uma "importação" como está sendo 
pensado; e é proposital. Entre outras razões, porque se você olhar com atenção 
o CNEFE, vai ver que é bem bagunçado, e quanto mais automatizada a "importação" 
(por mais bem organizada que seja), mais bagunça acabaria dentro banco de dados 
do OSM.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-be] Groen in de steden

[Santens Seppe]

Ik heb de discussie enkel diagonaal gelezen. Als ik het goed begrijp, zou er 
eigenlijk een tag moeten zijn die overeenkomt met het Nederlandse woord "perk" 
(Vandale: tuinvak met bloemen of planten). Ik denk wel dat het moeilijk is om 
daar in het Engels een goed equivalent voor te vinden.

Seppe

-Oorspronkelijk bericht-
Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: woensdag 11 januari 2017 17:28
Aan: OpenStreetMap Belgium
Onderwerp: [OSM-talk-be] Groen in de steden

Op het Nederlandse forum loopt een interessante discussie over het mappen van 
groen in de steden & gemeenten:
https://forum.openstreetmap.org/viewtopic.php?id=56899

Deze discussie loopt in parallel op de tagging mailing list.

m.

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