[talk-au] Tagging for NSW "State Conservation Area"?

[Warin]

What are the preferred tags for these areas?

In the past at least some of these were called "State Recreation Areas" and had 
recreation as their primary goal, with secondary goals of conservation.

Now, quoting from 
http://www.nationalparks.nsw.gov.au/conservation-and-heritage/state-conservation-areas,
 they have;

"State conservation areas are lands reserved to protect and
conserve significant or representative ecosystems, landforms, natural
phenomena or places of cultural significance. They provide opportunities
 for sustainable visitation, public enjoyment, and research.

The main difference between the management, objectives
and principles of national parks and state conservation areas is that
mineral and petroleum exploration and mining may be permitted in state
conservation areas."

I have

boarder=protected_area

name=* Conservation Area

website=*

and may add things like landcover=trees, natural=wood etc as appropriate ...

Any other thoughts?

I don't think they should be tagged as National Parks ..

Possible inclusions

leisure=nature_reserve


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

Re: [talk-au] Tagging for NSW "State Conservation Area"?

[cleary]

In most cases I add a relation as there are often shared boundaries or
multiple parts to the conservation area. My most recent addition was
today. The tags I used for the relation were;

type=boundary
boundary=protected_area
protect_class=4
name=Livingstone State Conservation Area
source=LPI NSW Administrative Boundaries NPWS Reserve
operator=National Parks and Wildlife Service NSW
website=http://www.nationalparks.nsw.gov.au/visit-a-park/parks/livingstone-national-park

I have rarely added natural=wood or natural=scrub but whole areas are
rarely uniform and it can be difficult to accurately describe the
landcover etc unless one has personally visited and surveyed the
conservation area.

I am reluctant to use a "leisure" tag unless it is clear the area has
that purpose. I think that visitors are not always encouraged in some
state conservation areas.

I am also interested in feedback from other mappers.




On Tue, Jan 26, 2016, at 05:20 PM, Warin wrote:
> What are the preferred tags for these areas?
> 
> In the past at least some of these were called "State Recreation Areas"
> and had recreation as their primary goal, with secondary goals of
> conservation.
> 
> Now, quoting from
> http://www.nationalparks.nsw.gov.au/conservation-and-heritage/state-conservation-areas,
> they have;
> 
> "State conservation areas are lands reserved to protect and
> conserve significant or representative ecosystems, landforms, natural
> phenomena or places of cultural significance. They provide opportunities
>   for sustainable visitation, public enjoyment, and research.
> 
> The main difference between the management, objectives
> and principles of national parks and state conservation areas is that
> mineral and petroleum exploration and mining may be permitted in state
> conservation areas."
> 
> I have
> 
> boarder=protected_area
> 
> name=* Conservation Area
> 
> website=*
> 
> and may add things like landcover=trees, natural=wood etc as appropriate
> ...
> 
> Any other thoughts?
> 
> I don't think they should be tagged as National Parks ..
> 
> Possible inclusions
> 
> leisure=nature_reserve
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [OSM-talk-fr] Problème de langue

[Damouns]

Moi je suis assez d'accord avec Jean-Yvon : je ne vois pas l'intérêt du
name= dans le cas d'un objet international comme ça. A la limite je verrais
bien des name:fr=, name:de=... mais pas de name= car en plus il est
redondant avec le ref.


Damouns

Le 26 janvier 2016 à 07:33, Dominique Faure  a
écrit :

> Donc si je résume par rapport à mon propos initial, il faudrait finir par
> avoir:
> => Une relation "name=European route 54", référençant:
> ==> 2 relations "name:fr=Route européenne 54" et "name:de=Europastraße 54"
> pour chaque portion nationale, référençant:
> ===> p segments élémentaires existants, nommés ou non suivant le cas.
>
> C'est ça?
> J'ai regardé un peu alentour, il semblerait que la route E60 présente déjà
> une structure similaire. Faut-il se caler dessus?
> Enfin, la question qui fâche, qui fait la modif? :)
>
>
> 2016-01-26 0:49 GMT+01:00 Philippe Verdy :
>
>>
>>
>> Le 25 janvier 2016 à 22:41, Jérôme Seigneuret 
>> a écrit :
>>
>>> Bonjour,
>>>
>>> J'appui Jean-Yvon pour le name
>>>
>>> Coté relation David à raison sur le fait de gérer des relations avec des
>>> niveaux multiples ce qui permet d'importer des portions ou de gérer des
>>> itinéraires logiques par étapes avec les différents niveau (local,
>>> régional, national...) d'où l'utilisation du name anglais sur une
>>> super-relation (en Europe quand ça traverse les frontières)
>>>
>>> Pour le check d'OSM c'est pas trivial sur le test du nom.
>>>
>>> Je reprends le cas de Philippe
>>> *Noms dans la langue locale et dans la langue par défaut différents*
>>> *way 83115947 *
>>> rawedit  josm
>>>  edit
>>> 
>>> *highway* = living_street
>>> *maxspeed* = 20
>>> *name* = Chemin des Bauches
>>> *name:fr* = Lotissement le Manoir
>>>
>>> Là on n'est vraiment pas sur une question de langue mais sur une
>>> incohérence de nom. C'est pas la traduction qui est testé mais juste une
>>> correspondance entre le territoire le name:[langue] et le name
>>>
>>
>> Je n'ai pas dit le contraire, seulement ton débat concernant le
>> territoire est hors sujet mais c'est pourtant le même test qui est fait :
>> trouver une correspondance entre un name:lang=* et le name=* Et Là Osmose
>> ne teste pas tous les name:lang=* mais se limite à chercher le name sur un
>> seul noeud pour lequel il détermine quelle devrait être "la" langue locale
>> et signale ensuite l'erreur sur la relation entière puisque alors le name=*
>> par défaut n'a pas la valeur du name:fr... Même si le noeud n'a qu'une
>> langue locale, ce n'est celle de la relation entière, hors le résultat
>> s'affiche pour la relation entière ou le chemin ou polygone entier. C'est
>> ça qui est défectueux: déterminer la langue locale d'une relation sur un
>> seul de ses noeuds (choisi en fait arbitrairement) ne peut pas marcher du
>> tout et donnera des résultats faux si l'objet n'est pas tout entier dans un
>> territoire linguistique unique (dans ce seul cas le noeud choisi
>> arbitrairement marchera puisqu'il fait partie de l'objet entièrement
>> contenu dans la même zone linguistique).
>>
>> Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
>> lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
>> sauf que la rue entière est dans le même territoire que le noeud choisi sur
>> ce chemin. Mais ça marche seulement à moitié.
>>
>> Je maintiens donc ce que je disais :
>>
>> - pas besoin de déterminer une langue locale (s'il y en a une malgré
>> tout, il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
>> langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
>> name=* qui peut rester différente (exemple courant : les noms par défaut en
>> Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
>> locale est le chinois ou l'arabe, mais il faudrait autant que possible
>> libeller précisément ce nom anglais aussi avec name:en=*)
>>
>> -  dans les pays ou régions officiellement multilingues on ne peut pas
>> déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
>> (pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
>> serait en fait une approximation grossière et que le nom romanisé serait en
>> fait issu d'une transliteration latine officielle telle que le romaji
>> japonais, ou les transliterations officielles ou universitaires du chinois
>> ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
>> et dans les échanges cartographiques internationaux, ou les
>> transliterations des organisemes internationaux pour l'aviation ou la
>> navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
>> dans les langues officielles mais il reste alors le choix du nom "par
>> défaut" qui 

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

Thanks for the feedback.

I seems like I always stumble upon cases like this (also with De Lijn,
house numbers, Dutch import). So no surprise that I am critical about
"imports" (or manually merged data from another DB). With your
procedure we can avoid that such data creeps into OSM, but you have to
be careful and not hurry the data merger to much.

Do we really need the source=GRB tag ? (not talking about
source:geometry). I don't like this tag (source) anymore. They are not
maintained, it's not clear to which part of the tags they apply and
just fill the database. When you survey a POI e.g., the name and type
of shop come from the picture you have taken, the position from the
georeferencing of the photo, combined with your memory and aerial
image, the building layout comes from AGIV (or GRB), the house number
from survey/GRB/CRAB, the webpage from a web search, etc. What is
source in that case ? Are you adding source:XXX for each different tag
?

regards

m

On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas  wrote:
> On 25-01-16 19:38, Marc Gemis wrote:
>> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  wrote:
 * splitting a building because the garage is clearly separated on AGIV 
 imagery
>>>
>>> You should not have to do that imho, I've never encountered this 'too
>>> much building in between' situation.  When the garage is separated
>>> visibly on sat images but not in GRB, that's a precarious case, it could
>>> be that the building has been replaced but GRB isn't up to date, it
>>> could also be that the sat pics used are out of date and there has been
>>> an additional construction already in GRB.  You can't tell now what is
>>> correct from combining al sources of information.
>>
>> It's in Kaprijke, oid 1964089 IMHO this is just sloppy work in GRB.
>> For those without access to GRB
>
> Absolutely right, it should be more like the neighbour’s house+garage.
> That is some really shitty data you have in that area there.  Someone
> really didn't bother being accurate.  They aren't even decent squares.
>
> These cases I've only seen a few of those.  I specifically remember a
> building crossing itself, like a closed '8' instead of an '0' or open 8
> like here (bit of imagination applies)
>
> I would remove that corner from the main building,  draw the garage
> yourself, tag it appropriately. The garage should in fact have it's own
> OIDN number in GRB data.
>
> Also, make sure when you create your better OSM bulding, tag it
> source:geometry=AGIV (I think to recognise agiv sats).
>
> Then whenever this gets into GRB and trickles down in OSM, you will get
> a merge pop-up here (because we use source:geometry=GRB for our building
> imports by default), instead of a silent merge...  you'll get notified
> there is a conflict, forcing you (=editor) to make a judgement call.
>
> Looks like pretty recent buildings.  Sloppy fieldwork indeed.
>
> It sure varies a lot the quality, probably by the decentralised approach
> to this.
>
>
> Nice catch.
>
> Glenn
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Bicycle highways

[Marc Gemis]

On Mon, Jan 25, 2016 at 9:58 PM, Matthieu Gaillet  wrote:
> This is however something that has to be discussed on a higher level than
> Belgium. Where is this place ?

As Glenn wrote, here is a good place to discuss first. When no
solution is found, or when you want to hear the opinion of a larger
community, you can discuss this on the tagging mailing list
But be prepared to have a discussion that goes on and on, and round
and round without getting to a conclusion. Only when you are lucky,
everybody will agree. :-)
Of course you might go to the Dutch and German fora only, because
there are large groups of cyclist there.

regards
m

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

Re: [OSM-talk-fr] Problème de langue

[Dominique Faure]

Donc si je résume par rapport à mon propos initial, il faudrait finir par
avoir:
=> Une relation "name=European route 54", référençant:
==> 2 relations "name:fr=Route européenne 54" et "name:de=Europastraße 54"
pour chaque portion nationale, référençant:
===> p segments élémentaires existants, nommés ou non suivant le cas.

C'est ça?
J'ai regardé un peu alentour, il semblerait que la route E60 présente déjà
une structure similaire. Faut-il se caler dessus?
Enfin, la question qui fâche, qui fait la modif? :)


2016-01-26 0:49 GMT+01:00 Philippe Verdy :

>
>
> Le 25 janvier 2016 à 22:41, Jérôme Seigneuret 
> a écrit :
>
>> Bonjour,
>>
>> J'appui Jean-Yvon pour le name
>>
>> Coté relation David à raison sur le fait de gérer des relations avec des
>> niveaux multiples ce qui permet d'importer des portions ou de gérer des
>> itinéraires logiques par étapes avec les différents niveau (local,
>> régional, national...) d'où l'utilisation du name anglais sur une
>> super-relation (en Europe quand ça traverse les frontières)
>>
>> Pour le check d'OSM c'est pas trivial sur le test du nom.
>>
>> Je reprends le cas de Philippe
>> *Noms dans la langue locale et dans la langue par défaut différents*
>> *way 83115947 * rawedit
>>  josm
>>  edit
>> 
>> *highway* = living_street
>> *maxspeed* = 20
>> *name* = Chemin des Bauches
>> *name:fr* = Lotissement le Manoir
>>
>> Là on n'est vraiment pas sur une question de langue mais sur une
>> incohérence de nom. C'est pas la traduction qui est testé mais juste une
>> correspondance entre le territoire le name:[langue] et le name
>>
>
> Je n'ai pas dit le contraire, seulement ton débat concernant le territoire
> est hors sujet mais c'est pourtant le même test qui est fait : trouver une
> correspondance entre un name:lang=* et le name=* Et Là Osmose ne teste pas
> tous les name:lang=* mais se limite à chercher le name sur un seul noeud
> pour lequel il détermine quelle devrait être "la" langue locale et signale
> ensuite l'erreur sur la relation entière puisque alors le name=* par défaut
> n'a pas la valeur du name:fr... Même si le noeud n'a qu'une langue locale,
> ce n'est celle de la relation entière, hors le résultat s'affiche pour la
> relation entière ou le chemin ou polygone entier. C'est ça qui est
> défectueux: déterminer la langue locale d'une relation sur un seul de ses
> noeuds (choisi en fait arbitrairement) ne peut pas marcher du tout et
> donnera des résultats faux si l'objet n'est pas tout entier dans un
> territoire linguistique unique (dans ce seul cas le noeud choisi
> arbitrairement marchera puisqu'il fait partie de l'objet entièrement
> contenu dans la même zone linguistique).
>
> Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
> lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
> sauf que la rue entière est dans le même territoire que le noeud choisi sur
> ce chemin. Mais ça marche seulement à moitié.
>
> Je maintiens donc ce que je disais :
>
> - pas besoin de déterminer une langue locale (s'il y en a une malgré tout,
> il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
> langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
> name=* qui peut rester différente (exemple courant : les noms par défaut en
> Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
> locale est le chinois ou l'arabe, mais il faudrait autant que possible
> libeller précisément ce nom anglais aussi avec name:en=*)
>
> -  dans les pays ou régions officiellement multilingues on ne peut pas
> déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
> (pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
> serait en fait une approximation grossière et que le nom romanisé serait en
> fait issu d'une transliteration latine officielle telle que le romaji
> japonais, ou les transliterations officielles ou universitaires du chinois
> ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
> et dans les échanges cartographiques internationaux, ou les
> transliterations des organisemes internationaux pour l'aviation ou la
> navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
> dans les langues officielles mais il reste alors le choix du nom "par
> défaut" qui devrait être comme c'est vu localement multilingue. Pour que ce
> nom par défaut corresponde à un des "name:lang=*" il suffit de l'indiquer
> aussi dans "name:mul=*", et le problème est résolu. Pas de problème ensuite
> pour n'afficher que l'anglais avec un "name:en=*" si nécessaire (notamment
> si le nom multilingue officiel utilise des écritures différentes telles que
> latin+arabe ou latin+sinogrammes).
>
> - quand le nom par 

Re: [OSM-talk] About the development of another Overpass API

[Tom Hughes]

On 26/01/16 06:36, Dongpo Deng wrote:


Last year, NCHC[1] started to host a caching server 'Longma' [2] for
serving Asia. They are now working on development of an instance of
Overpass API in Asia. To fetch data from OSM API, we're just wondering
which OSM APIs are available for this?


Overpass doesn't fetch data from any API so your question doesn't really 
make any sense.


It works by using the diffs to maintain it's own database and then 
provides an API based on that database.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-talk-fr] wiki : page sur les frontières

[Vincent de Château-Thierry]

Bonjour,

Le 26/01/2016 03:20, Philippe Verdy a écrit :

Le 26 janvier 2016 à 02:16, Jérôme Amagat > a écrit :

C'était déjà décrit dans la page sur les boundary et d'autres
pages liées (y compris pour les EPCI)

Le 26 janvier 2016 à 01:25, Jérôme Amagat
> a écrit :

J'ai écrit une page qui liste les frontières françaises et
les tags qui vont avec :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives

il manque plein de choses encore mais je pense que ça
pourrait être pas mal d'avoir quelque chose de ce type.
comme le nouveau tag admin_type qui je crois n'apparait nul
part sur le wiki. la page n'est pas la ou elle serai le mieux.

la page :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
devrait évolué aussi et mettre en valeur le fait
qu'aujourd'hui ce qui compte c'est la creation de commune
nouvelle et la modification des communauté de communes et
autres EPCI.


Ta page est très claire. Il me semble qu'il manque le tag name pour les 
arrondissements de PLM.


Comme dit par Philippe une telle page existe déjà :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#R.C3.A9capitulatif_en_France_des_tags_selon_le_niveau_administratif

Il faudrait se servir de ta page pour rafraichir le contenu et la 
présentation de l'autre, pour au final n'avoir qu'une page. 2 pages pour 
la même info c'est à coup sûr une source de confusion sur la durée, avec 
des écarts de mise à jour et donc des contradictions.


vincent

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

[OSM-talk] About the development of another Overpass API

[Dongpo Deng]

Dear all,

Last year, NCHC[1] started to host a caching server 'Longma' [2] for
serving Asia. They are now working on development of an instance of
Overpass API in Asia. To fetch data from OSM API, we're just wondering
which OSM APIs are available for this?

[1] http://www.nchc.org.tw/en/
[2] http://wiki.openstreetmap.org/wiki/Servers/longma

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

Re: [Talk-GB] Next UK chapter concall

[Dudley Ibbett]

Hi Brian

I think we should have "ordinary" members with full voting rights.  Another 
class of membership should be for "organisations".  They should be required to 
nominate an individual to represent them.  Their voting rights should be 
limited so they cannot vote for committee membership or stand on the committee.

At this time I would also suggest we set a minimum age for any type of 
membership to 18. I believe this would simplify issues when it come to 
complying with child protection legislation.

Apart form the initial cost of setting up any organisation.  I would guess the 
main annual cost will be insurance and auditor fees for the accounts.  This 
assumes that we won't be paying the committee expenses!   I'm aware of a couple 
of organisations that seem to do this for an annual fee of £25-£35 for ordinary 
membership.  Any "organisation" type of membership would need to be excluded 
from the insurance unless we got down an affiliate model along the lines of 
mountaineering clubs that affiliate to the BMC for example.

Kind Regards

Dudley




Sent from my iPad

> On 25 Jan 2016, at 18:36, Brian Prangle  wrote:
> 
> Hi everyone
> 
> Don't forget this is scheduled for 8pm Wed this week 27 January
> 
> 0800 22 90 900  Pass code 33224
> 
> We'll pick up on Rob's summary email i.e objectives;legal stucture; 
> constitution
> 
> If we can I'd like to start discussing:
> 
> Name (not what it will be - but a mechanism for choosing one)
> Membership classes, rights and costs
> 
> On objectives:the ensuing silence since draft 2 I'm not sure to take as 
> indifference or approval, but let's use the text as a starting point:
> 
> 1.To increase the size, skills, toolsets and cohesion of the OpenStreetMap 
> community in the UK.
> 
> 2.To promote and facilitate the use of OpenStreetMap data by organisations in 
> the UK.
> 
> 3.To promote and facilitate the release by organisations in the UK of 
> OpenData  that is suitable for use in OpenStreetMap.
> 
> On legal structures, please read Rob's excellent summary before the concall. 
> I've read it and my conclusion so far, and I'm still not clear on some 
> things, is that we shouldn't go for unincorporated society (unlimited 
> liablity for officers) or charity (we don't have a charitable purpose and the 
> legal strictures are a bit more complex than we'd want). From the rest I 
> think company limited by guarantee (that's what OSMF chose) suits us best. 
> Not sure yet whether CIO or CIC, given that we'd be non-profit, are worth 
> considering.
> 
> Look forward to "seeing" you Wed
> 
> Regards
> 
> Brian
> ___
> 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-be] Agiv import

[Marc Gemis]

On Tue, Jan 26, 2016 at 1:48 AM, Glenn Plas  wrote:
> Also, make sure when you create your better OSM bulding, tag it
> source:geometry=AGIV (I think to recognise agiv sats).

What do I have to do with source:geometry:date in those cases ?

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

Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

[Ross]

On 25/01/16 20:36, Ian Sergeant wrote:

On 25 January 2016 at 19:38, Ross  wrote:


And the guess does not get fixed there are many locations where roads are
still on admin boundaries but the boundary is no long there (changes to
boundaries) or the road has moved but  nobody comes back to correct it.


To me this seems like a more general problem.  Mapping bare areas gets
done, but when a road moves or a boundary moves then they don't tend
to get noticed as much.  After the ABS2006 data was imported, it
wasn't linked to features, but quickly fell out of date as suburbs
changed and were added.

Ian.

There was plenty of linking to roads/rivers/railways with this import.

They are still to be found in the database.

Cheers
Ross


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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 25-01-16 14:06, Marc Gemis wrote:
> What's the planning for the import ?
> 
> * Glenn finishes documentation (although I think it's (almost) ready)

The highlights are ready, but I've encountered plenty of situations that
we will run into that need more detailed documentation.  I've made some
movies as well showing how I worked but I might have to do them again
since I had to change some ways after Sander's valuable input.

The tool isn't quite done yet imho. I still need to fix/improve a few
things in the code.  Also, after-care is important.  I want the script
to also be able to verify if buildings were updated.  Once the GRB
reference (oidn) is in the OSM data we can reference it to compair
(using the source date) if any updates have been done to existing buildings.

> * We pass this somehow through the import mailing list ( I fear we
> cannot avoid this). Sander, you have some experience with this. What
> do you think ?

This needs to pass indeed, but let's not call it an import from now on.
 I prefer a "semi-automated, human reviewed, merge operation" :)
It is a bit like the news calling it a "tactical bombardment" when
blowing up bombs, the first almost sounds like there aren't any
casualties at all.

> * We have a face-to-face meeting / hangout to explain the procedure to
> interested people.  Face-to-face is better I think, but might not be
> feasible for everyone. Perhaps a combination ?

I believe face-2-face is better, and I'm willing to spend time on this,
there are many questions you will have and the interactive approach will
be easier to answer/demonstrate instead of describing it.

> * We start "the import". Somehow we need an overview for this to see
> who is working on a certain town. (a shared document/spreadsheet)

I don't think you really need that in order to be able to work (it
wouldn't hurt though).  Version management will take care of people
working on different areas, in case of conflicts (I had a few where
buildings where updated after my data retrieval from OSM and before
uploading changesets) it's not fun resolving those in JOSM (even hard
sometimes).

So I would suggest doing it in small fractions. I tried 'finding'
building hotspots and just work square per square.  You can also to the
'bijgebouwen' first and then later the main buildings, after that
garages and so on...  So it doesn't have to be segregated into area's ,
you could just do subsets.

The only thing you need to keep track of is the work you've done
yourself.  I deleted the buildings from the source file once I moved
them to the target layer, to avoid duplicate validation work.

The area size was not always as large, it depends on the concentration
of buildings.  We should discuss this at the meeting, because I'm just a
one man show and would love some peer input and feedback.

I was thinking about using HOT osm task manager, it's code is available.
 That would be awesome to

https://github.com/hotosm/osm-tasking-manager2

Then there is also the matter of downloading (Aka `Ordering`) the data.
We should do this 'at once' preferably to make sure adjacent areas match
up. Not doing so might give some problem at the borders of the area.
But that should be minimal.

There are 307 'gemeentes' / general area's in the selection list.  You
can combine some, but I haven't tried to combine all for a full download.

Glenn

> 
> 
> 
> m.
> 
> 
> On Mon, Jan 25, 2016 at 9:55 AM, Glenn Plas  wrote:
>>
>>> I also mean when the geometry in OSM is actually better than in
>>> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>>>  building shape is just wrong. In OSM it's better (may be not
>>> perfect, it's a complex building) and 3D mapped.
>>> http://www.openstreetmap.org/#map=18/51.18741/3.20325
>>
>> Yes of course. that's why I call it a merge. since this process
>> encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
>> not hard to see where GRB has got it wrong.
>>
>> No need to worry about losing good OSM data, when done right..
>>
>> Glenn
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [Talk-it] Materiale per "OSM per ciclisti"

[Volker Schmidt]

>
> Hai già stabilito luoghi e date, o almeno al nord e al centro avevi idea
> delle città?
>

Le città candidati sono Milano, Verona, Mestre o Padova nel nord e Roma o
Arezzo al centro.
Ma la scelta del posto dipende non solo da me.
Quello che manca è buono materiale didattico da consegnare ai partecipanti.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Couverture voies et noms de voies

[Florent RICHARD]

Bonjour,

Pour le nom des voies, tu as ce site 
http://qa.poole.ch/?zoom=7=46.46741=3.77173=TFFFB0 qui 
affiche en rouge toutes les routes qui ne portent ni tag "name" ni de "ref" 
dans OSM. Il concerne toutes les voies, pas seulement les voies définies 
dans le FANTOIR.
Le rendu BANO 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#6/46.294/6.064 est 
fait pour les adresses mais il pourra t'indiquer si le nom d'une rue est 
absente d'OSM (tout ce qui est en rouge). voir la légende 
http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#L.C3.A9gende


Pour ce qui est des % par département, je ne connais pas d'outil.

Florent
-Message d'origine- 
From: Bruno

Sent: Monday, January 25, 2016 12:02 PM
To: Discussions sur OSM en français
Subject: [OSM-talk-fr] Couverture voies et noms de voies

Bonjour,

Dans le cadre d'un projet en entreprise et pour convaincre de l'utilité
d'OSM , j'aurais besoin de montrer de façon simple et visuelle la
couverture actuelle de la base OSM en ce qui concerne la voirie  et le
noms des voies , pas les adresses ni le bâti.

Un peu comme tiles et les zones à mapper mais juste le rouge et avec par
exemple un % de noms des voies par département.
http://tile.openstreetmap.fr/

Si il existe déjà quelque chose je suis preneur.

Cordialement,
Bruno.

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



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

Re: [Talk-it] WTOSM

[Alessandro Palmas]

Il 25/01/2016 15:32, Luca Delucchi ha scritto:


ale prova http://www.geodati.fmach.it/ e
http://www.geodati.fmach.it/gfoss_geodata/osm/wtosm/it_IT/index_2.html




OK !!
Grazie Luca!

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

Re: [OSM-talk-be] Agiv import

[Sander Deryckere]

2016-01-25 15:37 GMT+01:00 Glenn Plas :

> On 25-01-16 14:06, Marc Gemis wrote:
> > * We pass this somehow through the import mailing list ( I fear we
> > cannot avoid this). Sander, you have some experience with this. What
> > do you think ?
>
> This needs to pass indeed, but let's not call it an import from now on.
>  I prefer a "semi-automated, human reviewed, merge operation" :)
> It is a bit like the news calling it a "tactical bombardment" when
> blowing up bombs, the first almost sounds like there aren't any
> casualties at all.
>
> I'm confident we'll get through it even when calling it an import. The
data quality is good, we're with a limited set of active mappers (who
worked on OSM long before trying an import), and we care about our region.

The only thing I'd have to defend is the usage of the GRB. They'd need some
guarantee that the key is valid (won't change without a reason, and won't
be reused on another building). I guess the AGIV gives some guarantee for
it in their documentation, but we should make the clear.


> > * We have a face-to-face meeting / hangout to explain the procedure to
> > interested people.  Face-to-face is better I think, but might not be
> > feasible for everyone. Perhaps a combination ?
>
> I believe face-2-face is better, and I'm willing to spend time on this,
> there are many questions you will have and the interactive approach will
> be easier to answer/demonstrate instead of describing it.
>

Face-2-face sounds good.

>
> > * We start "the import". Somehow we need an overview for this to see
> > who is working on a certain town. (a shared document/spreadsheet)
>
> I don't think you really need that in order to be able to work (it
> wouldn't hurt though).  Version management will take care of people
> working on different areas, in case of conflicts (I had a few where
> buildings where updated after my data retrieval from OSM and before
> uploading changesets) it's not fun resolving those in JOSM (even hard
> sometimes).
>
> So I would suggest doing it in small fractions. I tried 'finding'
> building hotspots and just work square per square.  You can also to the
> 'bijgebouwen' first and then later the main buildings, after that
> garages and so on...  So it doesn't have to be segregated into area's ,
> you could just do subsets.
>

Yes, it should be organised in a way you can do an hour or two work on it,
upload it, and return later on with fresh OSM data to avoid conflicts.

>
> The only thing you need to keep track of is the work you've done
> yourself.  I deleted the buildings from the source file once I moved
> them to the target layer, to avoid duplicate validation work.
>
> We could set up a map for this. You can overlay mapbox vector tile
buildings with a GRB background, and see where any GRB buildings stick out,
or the other way around.

We can also use overpass to do some counting in squares or boundaries. F.e.
in Overpass, it would be easy to extract a list of all GRB ids of buildings
in a certain municipality, and compare that with the official data.


> The area size was not always as large, it depends on the concentration
> of buildings.  We should discuss this at the meeting, because I'm just a
> one man show and would love some peer input and feedback.
>
> I was thinking about using HOT osm task manager, it's code is available.
>  That would be awesome to
>
> https://github.com/hotosm/osm-tasking-manager2
>
> Then there is also the matter of downloading (Aka `Ordering`) the data.
> We should do this 'at once' preferably to make sure adjacent areas match
> up. Not doing so might give some problem at the borders of the area.
> But that should be minimal.
>
> There are 307 'gemeentes' / general area's in the selection list.  You
> can combine some, but I haven't tried to combine all for a full download.
>

I ran into the problem of not being able to download it all. My internet
connection isn't stable enough, and when the connection drops, the download
can't be resumed.

But even when you're able to download everything, you should still be able
to split the shapefile. Not all shapefile splitters will work, as some just
run in your memory (and I guess you don't have more than 15 GB RAM).

OSM tasking manager indeed seems like a good idea (it's also used by other
countries to organise imports), and the tasking manager can even provide
links to external files in some way (I've used it when doing an import of
names in Sierra Leone once).

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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

On 25-01-16 14:54, Marc Gemis wrote:
> So you are saying a need a couple of weeks more to finalise the tool.

More like a few hours (2/3 hrs). Cleanup the code a bit, perhaps remove
all my chaos inline documentation anchors :)

The verification part (with overpass stuff built in), I can write that
later, it's not too difficult.  Like Sanders state in his most recent
reply: this all depends on the uniqueness and stability of the 'oidn'
reference field, this key is the most important one.

> Then 2-3 weeks discussion on the import mailing list

It could be long, it could go fast too, I don't see us discussing this
too deeply.

> which means we could plan a face-to-face meeting in 2 months ?

For me it's ok to do this sooner, I really don't want to wait another 2
months to start on this, summer is coming and this is going to keep me
inside :)

> 
> I think that planning a face-to-face meeting can start now, so people
> that are interested can keep a day free in their agenda.

I'm setting up the HOT task manager as we speak, it's well documented,
this could be the perfect management tool.  I'll complete the setup asap.

Glenn


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

Re: [Talk-it] Materiale per "OSM per ciclisti"

[Alessandro Palmas]

Il 23/01/2016 20:01, Volker Schmidt ha scritto:
Mi sono impegnato di organizzare dei mini-corsi all'interno della FIAB 
(Federazione Italiana Amici della Bicicletta) su come inserire dati 
rilevanti per ciclisti in OSM. L'accento dovrebbe essere su:


  * aspetti delle strade rilevanti per ciclisti
  * ciclopiste
  * ciclovie (relazioni)
  * controllo di qualità (in particolare delle relazioni per le ciclovie)

Devo preparare una dispensa e per questo cerco materiale ed idee.
Se qualcuno mi vuole dare una mano anche per gli eventi stessi, sarei 
più che contento.
Penso a due o tre eventi di un giorno, uno al nord, uno nel centro e 
uno nel sud.


Volker
(Padova)



Hai già stabilito luoghi e date, o almeno al nord e al centro avevi idea 
delle città?


Alessandro Ale_Zena_IT

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

[Talk-de] Forschungsstation Antarktis

[Markus]

Da war neulich ein Link
zu einer toll kartografierten Forschungsstation in der Antarktis...

Wer kann mir damit helfen?

Gibt es ein tolles Beispiel für Mikro-Kartografie?

und für 3D?

Mit herzlichem Gruss,
Markus

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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

What's the planning for the import ?

* Glenn finishes documentation (although I think it's (almost) ready)
* We pass this somehow through the import mailing list ( I fear we
cannot avoid this). Sander, you have some experience with this. What
do you think ?
* We have a face-to-face meeting / hangout to explain the procedure to
interested people.  Face-to-face is better I think, but might not be
feasible for everyone. Perhaps a combination ?
* We start "the import". Somehow we need an overview for this to see
who is working on a certain town. (a shared document/spreadsheet)



m.


On Mon, Jan 25, 2016 at 9:55 AM, Glenn Plas  wrote:
>
>> I also mean when the geometry in OSM is actually better than in
>> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>>  building shape is just wrong. In OSM it's better (may be not
>> perfect, it's a complex building) and 3D mapped.
>> http://www.openstreetmap.org/#map=18/51.18741/3.20325
>
> Yes of course. that's why I call it a merge. since this process
> encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
> not hard to see where GRB has got it wrong.
>
> No need to worry about losing good OSM data, when done right..
>
> Glenn
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-fr] Couverture voies et noms de voies

[Vincent de Château-Thierry]

Bonjour,

> De: "Florent RICHARD" 
> 
> Pour ce qui est des % par département, je ne connais pas d'outil.

Il y a bien ça :
http://cadastre.openstreetmap.fr/fantoir/stats_dept.html
mais ça n'a rien de visuel, juste des tableaux de chiffres. Et le niveau 
d'agrégation est la commune, même si la présentation est par département. On 
doit pouvoir simplement à partir du même matériau sortir des chiffres par 
département.
À noter spécifiquement sur NPDC les pages http://legosm.fr/bano5962/ dont 
http://legosm.fr/bano5962/tableauBord.php

vincent

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

Re: [OSM-talk-fr] Pb sur polygons.openstreetmap.fr ?

[Philippe Verdy]

normalement ce n'est pas par exclusion qu'il faut procéder mais par
inclusion : ne pas parcourir ce qu'on ne connait pas, juste ce qu'on
connait, donc juste le rôle vide par défaut (pour les membres de type way),
et les rôles "inner"/"outer" (pour les ways), "admin_centre" (pour les
noeuds : attention il est normal que certaines relations en ait deux), et
"subarea" (usage limité encore un seul trype de découpage, incompatible
avec plusierus découpages orthogonaux).
Le rôle "collection" est là en attendant de trouver mieux (j'avais pensé à
un rôle "subareas" au pluriel pour ces relations contenant des subareas
pour chaque type de découpage, plutôt qu'un type pour l'instant générique
"collection")

Noter aussi que pour certains découpages les membres "subarea" pevuent
êrtre eux-même de types différents (par exemple mélange de frontières
administrative sde niveaux différents, on a le cas en France avec les
cantons, aussi bien en ancienne et nouvelle version, car ils groupent des
communes, ou des fractions de communes, ou des communes déléguées ou des
communes associées). Les textes légaux font répférences à ces types
différents d'entités pour mentionner la composition effective d'une autre
entité plus grande ; on a le cas aussi pour les EPCI, notamment les
syndicats mixtes ; ou encore pour la Metropole du Grand Paris composée
d'une commune et d'une série d'EPT, eux-mêmes composés de communes). Comme
les découpages sont d'une grande complexité à suivre et gérer, il n'est pas
simple du tout de rétablir en se basant uniquement sur les admin_level des
ways (qui souvent sont supprimés et remplacés par d'autres qui n'ont pas
l'info) et souvent on n'a pas gardé de lien simple vezrs la source pour
revérifier.

Les découpages en "subarea" (groupés éventuellement en collections quand il
y a plusieurs découpages concurrents) sont une grande aide pour retrouver
le tout et vérifier la complétude et l'exactitude. Certes on a "
layers.openstreetmpa.fr" mais il omet de vérifier plein de choses et il ne
sait pas non plus analyser correctement les découpages politiques (cantons,
circonscriptions législatives) et n'nalyser pas non plus tout un tas
d'autres entités. Il ne sait pas plus analyser les découpages postaux, les
découpages de certains EPCI (notamment Nantes Métropole). De plus son temps
de réponse est très long pour se mettre à jour.

Enfin il y a des exceptions nombreuses au modèle hiérarchique. Un exemple:
les cantons avant 2015 sont la composante des arrondissements et des
circonscriptions législatives, mais ils ne correspondent plus aux nouveaux
cantons qui ne suivent plus les limites administratives; ces cantons sont
aussir restés formés sur des communes devenues aujourd'hui des communes
déléguées ou associées au niveau 9 et plus au niveau 8, ou qui ont fusionné
en fusion simple et sont passés en niveau 10. Quand les communes changes de
statut leur frontières sont aussi redessinées parfois et il est difficile
de suivre les modifs nécessaires sachant que d'autres entités sont
redéssinées (oui pour les EPCI mais il y a une période transitoire d'un
mois, mais non pour les cantons)


Le 19 janvier 2016 à 13:41, Jocelyn Jaubert  a
écrit :

> Bonjour,
>
> (désolé pour le retard, cet email était tombé dans ma boîte à spam :( )
>
> On Sun, Jan 03, 2016 at 03:32:54PM +0100, Antoine Riche wrote:
> > Le générateur de polygones a l'air d'avoir des soucis. sur une
> > relation qui semble correcte dans JOSM et
> > http://analyser.openstreetmap.fr/, le générateur de polygone
> > retourne une erreur. Par exemple
> > http://polygons.openstreetmap.fr/?id=4607815
>
> Je pense qu'il s'agit d'un souci avec la relation collection 4660205
> inclue par
> cette relation (le site web parcourt toutes les sous relations pour en
> sortir
> le polygone "général").
>
> On enlève déjà les roles suivants dans le parcours, peut-être qu'il
> faudrait
> rajouter "collection":
> ["subarea", "land_area", "disputed_exclave"])
>
>
> Je creuserais dans la soirée.
>
> --
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] WTOSM

[Alessandro Palmas]

Il 06/11/2015 14:23, Simone Cortesi ha scritto:

Ciao,
mi spiegate perche' in
http://geodati.fmach.it/gfoss_geodata/osm/wtosm/it_IT/index_2.html



Scusate,
questo è l'unico link a WTOSM? Ho provato l'acceso ma è giù

Alessandro Ale_Zena_IT

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

Re: [Talk-it] WTOSM

[Luca Delucchi]

2016-01-25 15:02 GMT+01:00 Alessandro Palmas :
>
> Scusate,
> questo è l'unico link a WTOSM? Ho provato l'acceso ma è giù
>

si, mmm strano. se arrivi fino qui [0] funziona, poi la pagina dei
dati funziona mentre wtosm e il confronto no cerco di investigare,
ma non ho molto tempo oggi

> Alessandro Ale_Zena_IT
>


[0] http://geodati.fmach.it/gfoss_geodata/osm/

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

[OSM-co] Mapeado cerca de la U Javeriana de Bogotá

[Andres Gomez Casanova]

Saludos a todos los maderos,

He visto que por cercanías de la Universidad Javeriana de Bogotá hay varios 
elementos mapeados, principalmente edificios.
Por los tiempos en que se han realizado los changesets, pareciera que como 
parte de una asignatura consistiera mapear los alrededores de la universidad y 
otras zonas de Bogotá.

Sin embargo, dichas modificaciones no tienen en cuanto muchos elementos de 
mapeo, y se están creando edificios con nodos compartidos con las calles, lo 
cual es incorrecto.

Deberíamos revisar esa zona para corregir los problema, y por qué no intentar 
contactar al profesor de la asignatura para que estos cursos de mapeo no sean 
solo para estudiantes sino para la comunidad.

Cordialmente,



Andres Gomez
AngocA
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-it] WTOSM

[Alessandro Palmas]

Il 25/01/2016 15:08, Luca Delucchi ha scritto:


si, mmm strano. se arrivi fino qui [0] funziona, poi la pagina dei
dati funziona mentre wtosm e il confronto no cerco di investigare,
ma non ho molto tempo oggi


[0] http://geodati.fmach.it/gfoss_geodata/osm/



Non accedo nemmeno a http://geodati.fmach.it/

OK Luca, grazie

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

Re: [Talk-it] WTOSM

[Luca Delucchi]

2016-01-25 15:13 GMT+01:00 Alessandro Palmas :

>
> Non accedo nemmeno a http://geodati.fmach.it/
>

ale prova http://www.geodati.fmach.it/ e
http://www.geodati.fmach.it/gfoss_geodata/osm/wtosm/it_IT/index_2.html


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

So you are saying a need a couple of weeks more to finalise the tool.
Then 2-3 weeks discussion on the import mailing list
which means we could plan a face-to-face meeting in 2 months ?

I think that planning a face-to-face meeting can start now, so people
that are interested can keep a day free in their agenda.

m.

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

Re: [Talk-es] Dudas de novato

[ihg]

¡Muchas gracias a todos por vuestra ayuda!

Cuando decimos que "los datos de OSM" son libres... ¿a qué tipo de datos nos 
referimos? ¿A las coordenadas donde está una ciudad? ¿O a las imágenes de las ciudades, 
con sus calles, etc.?

En resumen, el proyecto que tengo en mente necesitaría abarcar la totalidad del 
planeta y un usuario marcaría un punto en concreto. En mi base de datos sería 
yo el que almacenaría todos esos puntos, pero necesito un sistema que:

 * Dibuje las ciudades y sus calles
 * Buscador de lugares (por ejemplo, que ponga “Madrid” y me sitúe el mapa en 
Madrid)

Por tanto…

1. ¿Qué es lo que necesito? ¿Con OSM a secas me
   vale? ¿Algún servidor que me proporcione los “dibujos” de los mapas? ¿Un 
buscador externo?
   Si me podéis aclarar este batiburrillo os lo agradecería mucho :)
2. Cuando un servicio como MapQuest te permite 15.000 visualizaciones al mes, 
¿a qué se refiere? No sé si se refiere a que cuando yo pongo “Madrid”, la 
imagen que veo en mi ordenador se compone de 10 cachitos.
   ¿Ya me quedarían 14.990 visualizaciones o funciona de otra manera?

¡Gracias!

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

Re: [OSM-talk-fr] Problème de langue

[Philippe Verdy]

En revanche Osmose a raison pour:

*Noms dans la langue locale et dans la langue par défaut différents*
*way 83115947 * rawedit
 josm
 edit

*highway* = living_street
*maxspeed* = 20
*name* = Chemin des Bauches
*name:fr* = Lotissement le Manoir
*service* = alley
*source* = cadastre-dgi-fr source : Direction Générale des Impôts -
Cadastre;mise à jour :2010
Signalement reporté le : 2016-01-25

Effectivement ce nom par défaut ne correspond pas au nom indiqué pour le
français (seule langue indiquée). Ce message est en fait trompeur car il
suppose une langue "locale" (une seule). Mais ici les deux noms sont en
français mais ne nomment pas la même chose (l'un une rue, l'autre un
lotissement autrement dit un nom approprié pour un point ou polygone
"place=*")

Le nom du lotissement est en trop et ne devrait pas être là. Le name=* est
suffisant car il n'y a pas d'autre langue que la langue par défaut (qu'il
n'est pas nécessaire de préciser comme étant "la" langue locale ni même
explicitement que c'est du français)

Autre problème avec des noms par défaut oficiellement multilingues
- Exemple name="België - Belgique - Belgien", alors qu'on a
"name:fr=Belgique", "name:nl=België", "name:de=Belgien" : la valeur par
défaut ne correspond à aucune des langues mentionnées, c'est une
concaténation des noms dans plusieurs langues avec un séparateur, Osmose ne
sait pas analyser ça, la formule est assez compliquée en fait car
combinatoire :
- l'ordre est quelconque et il y a 6 possibilités avec 3 noms,
- et les séparateurs du nom multilingue par défaut varient, selon les
endroits (exemple en Espagne entre l'espagnol castillan et le basque ou le
catalan), entre "-" ou "/" ou ";", avec ou sans espaces, voire juste une
espace comme dans les noms multilingues au Maroc en français, arabe et
tamazigh (on a aussi parfois aussi l'anglais plutôt que le français dans
les noms par défaut alors que l'anglais n'est pas officiel et pas mentionné
non plus dans "name:en=*" où il devrait être...)





Le 25 janvier 2016 à 20:04, Philippe Verdy  a écrit :

> Là Osmose a clairement tord, ce qu'il considère comme "langue locale" (et
> la seule possible) est celle au point qu'il indique alors que c'est un way
> qui couvre plusieurs pays.
>
> Cas particulier si une langue indiquée en "name:lang=*" est une langue
> régionale non officielle, et même si c'est la même valeur dans la langue
> locale officielle, il faudrait la copier aussi pour cette langue
> officielle, sinon le mécanisme de "fallback" ne fonctionne pas et risque de
> prendre l'autre valeur dans "name=*" si aucune autre name:lang=*" ne
> correspond à cetle langue officielel majeure.
>
> Exemple: "name:br=*" mentionne un nom en breton, et "name=*" donne le nom
> en anglais (cette valeur peut aussi être dans "name:en=*") qui servira
> aussi de langue par défaut pour le français, alors que même en français on
> utilise le nom breton: copier "name:br=*" dans "name:fr:*" (et alors peu
> importe si "name=*" reste la valeur en anglais, qui devrait cependant être
> aussi dans "name:en=*")
>
> Dans le cas présent, Osmose a trouvé un point situé en France et suppose
> que c'est nécessairement du français pour toute la route alors qu'elle est
> internationale et ne se limite pas à ce seul point. Osmose pourrait éviter
> son erreur en voyant qu'on a pourtant un "name:fr=*" indiqué même si elle
> est diférente de la valeur par défaut (il a déterminé pour cette route que
> ce seul point devrait avoir au moins une valeur en français, il ne dtoit
> pas conclure que c'est la seule valeur possible pour toute la route)
>
> La seule chose que devrait faire Osmose c'est vérifier que name="*"
> conrrespond à une des valeurs "name:lang=*".
> - soit il n'y a aucune "name:lang=*" alors il faut un "name=*" par défaut
> utilisable dans toutes les langues
> - soit il y a au moins une valeur "name:lang=*" alors il doit exister
> aussi une 'name=*" de même valeur que l'une QUELCONQUE (peut-être
> plusieurs, peu importe) des langues indiquées dans "name:lang=*"
>
>
> Le 25 janvier 2016 à 19:06, Gautier Pelloux-Prayer  a
> écrit :
>
>> Non, je ne crois pas :
>> http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==
>>
>> La langue anglaise est bien dans la liste, mais au moins
>> osmose.openstreetmap.fr n'est pas content. Ou alors tu parles uniquement
>> pour les highways...
>>
>>
>> Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a
>> écrit :
>>
>> Osmose est content quand au moins un des noms "name:lang=*" correspond à
>> celui indiqué dans "name=*".
>>
>> Bref renseigner un nom dans "name=*" (langue quelconque) et dans
>> "name:fr=*"
>>
>> Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
>> écrit :
>>

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  wrote:
>> * splitting a building because the garage is clearly separated on AGIV 
>> imagery
>
> You should not have to do that imho, I've never encountered this 'too
> much building in between' situation.  When the garage is separated
> visibly on sat images but not in GRB, that's a precarious case, it could
> be that the building has been replaced but GRB isn't up to date, it
> could also be that the sat pics used are out of date and there has been
> an additional construction already in GRB.  You can't tell now what is
> correct from combining al sources of information.

It's in Kaprijke, oid 1964089 IMHO this is just sloppy work in GRB.
For those without access to GRB

https://xian.smugmug.com/OSM/Screenshots/Screenshots-1/i-JS8qrcz
https://xian.smugmug.com/OSM/Screenshots/Screenshots-1/i-74hZpVR

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

Re: [OSM-talk-fr] faire passer voie ferrée sur pont

[osm . sanspourriel]

Tu a aussi le droit de corriger ;-)

Le 25/01/2016 19:04, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Le 25/01/2016 18:42, lenny.libre a écrit :

josm m'envoie l'avertissement suivant :



Ce n'est qu'un avertissement. Ce n'est nullement lié à tes 
modifications de tes deux chemins, mais comme en modifiant une zone 
JOSM à téléchargé la voies ferrée, il t'annonce les avertissements de 
ce qu'il à chargé. Donc laisse JOSM te dire cela pour les voies ferrée.



Cordialement


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

Re: [OSM-talk-fr] faire passer voie ferrée sur pont

[Philippe Verdy]

Les avertissements portent sur un noeud. Un point ou un tunnel ne peut pas
être un noeud, ce doit être un segment de chemin...
Les noeuds dans les relations "route" sont pour les arrêts (stop : il faut
un rôle explicite, ne pas utiliser le rôle vide qui n'est admis en
compatibilité que pour les ways membres ; et c'esdt indépendant des
attributs du noeud lui-même qui peut ne pas avoir été chargé avec la
relation mais ce n'est pas nécessaire tant que le rôle est là et est
associé à un noeud même "incomplet").


Le 25 janvier 2016 à 19:04, David Crochet  a écrit :

> Bonjour
>
> Le 25/01/2016 18:42, lenny.libre a écrit :
>
>> josm m'envoie l'avertissement suivant :
>>
>
>
> Ce n'est qu'un avertissement. Ce n'est nullement lié à tes modifications
> de tes deux chemins, mais comme en modifiant une zone JOSM à téléchargé la
> voies ferrée, il t'annonce les avertissements de ce qu'il à chargé. Donc
> laisse JOSM te dire cela pour les voies ferrée.
>
>
> Cordialement
> --
> David Crochet
>
> ___
> 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] Problème de langue

[Philippe Verdy]

Là Osmose a clairement tord, ce qu'il considère comme "langue locale" (et
la seule possible) est celle au point qu'il indique alors que c'est un way
qui couvre plusieurs pays.

Cas particulier si une langue indiquée en "name:lang=*" est une langue
régionale non officielle, et même si c'est la même valeur dans la langue
locale officielle, il faudrait la copier aussi pour cette langue
officielle, sinon le mécanisme de "fallback" ne fonctionne pas et risque de
prendre l'autre valeur dans "name=*" si aucune autre name:lang=*" ne
correspond à cetle langue officielel majeure.

Exemple: "name:br=*" mentionne un nom en breton, et "name=*" donne le nom
en anglais (cette valeur peut aussi être dans "name:en=*") qui servira
aussi de langue par défaut pour le français, alors que même en français on
utilise le nom breton: copier "name:br=*" dans "name:fr:*" (et alors peu
importe si "name=*" reste la valeur en anglais, qui devrait cependant être
aussi dans "name:en=*")

Dans le cas présent, Osmose a trouvé un point situé en France et suppose
que c'est nécessairement du français pour toute la route alors qu'elle est
internationale et ne se limite pas à ce seul point. Osmose pourrait éviter
son erreur en voyant qu'on a pourtant un "name:fr=*" indiqué même si elle
est diférente de la valeur par défaut (il a déterminé pour cette route que
ce seul point devrait avoir au moins une valeur en français, il ne dtoit
pas conclure que c'est la seule valeur possible pour toute la route)

La seule chose que devrait faire Osmose c'est vérifier que name="*"
conrrespond à une des valeurs "name:lang=*".
- soit il n'y a aucune "name:lang=*" alors il faut un "name=*" par défaut
utilisable dans toutes les langues
- soit il y a au moins une valeur "name:lang=*" alors il doit exister aussi
une 'name=*" de même valeur que l'une QUELCONQUE (peut-être plusieurs, peu
importe) des langues indiquées dans "name:lang=*"


Le 25 janvier 2016 à 19:06, Gautier Pelloux-Prayer  a
écrit :

> Non, je ne crois pas :
> http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==
>
> La langue anglaise est bien dans la liste, mais au moins
> osmose.openstreetmap.fr n'est pas content. Ou alors tu parles uniquement
> pour les highways...
>
>
> Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a
> écrit :
>
> Osmose est content quand au moins un des noms "name:lang=*" correspond à
> celui indiqué dans "name=*".
>
> Bref renseigner un nom dans "name=*" (langue quelconque) et dans
> "name:fr=*"
>
> Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
> écrit :
>
>> Bonjour,
>>
>> Si cela peut aider au débat, il y a le "même" problème pour les Alpes :
>> http://www.openstreetmap.org/relation/2698607
>>
>> Osmose n'est pas content car on utilise par défaut le nom Anglais, mais
>> en même temps je vois pas de bonne solution pour qu'il le soit en l'état...
>> ? La solution de ne pas avoir de nom du tout serait pour moi la plus
>> logique, mais osmose ne sera toujours pas satisfait il me semble.
>>
>>
>> Le 25/01/2016 18:37, rainerU a écrit :
>>
>>> Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>>>
name=European route E 54

>>> Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
>>> le signalement Osmose et cela ne correspond à aucune réalité, car c'est
>>> une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
>>> anglais. La solution qui refléterait le mieux la réalité serait de ne
>>> pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
>>> faut absolument un attribut name=* il faut couper la relation en une
>>> partie française et une partie allemande et les regrouper dans une
>>> relation qui aura comme nom "Route européenne 54 / Europastraße 54".
>>>
>>> Le plus simple serait de faire comme pour d'autres routes du même type,
>>> c'est à dire de supprimer tous les attributs name. Si on veut on peut
>>> toujours construire un nom à partir des tags network et ref :
>>>
>>> https://www.openstreetmap.org/relation/2148632
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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: [Talk-GB] [Imports] OSM with Wikidata: 27232 matches found in England

[Edward Betts]

Dan S  wrote:
> I'm curious how The Shard ended up matching against its correct match
> but also London Bridge station? The station doesn't seem to have any
> matching metadata:
> http://edwardbetts.com/osm-wikidata/england/region/Greater_London/Apartment_buildings

The criteria for an apartment building is just anything tagged as a building
or landuse=residential

The Shard has an alias of 'London Bridge tower', my software trims these
endings from apartment building names to find more matches: house, apartments,
estate, and tower.

I might add 'building=train_station' as an exclusion for the apartment
building matching.

The matcher will be changed to say if there is an OSM object who's name
matches without trimming names, then it takes priority.

> I managed to find a few erroneous one-to-one matches in London:
> Q12048395 — The Queen's Walk (South Bank) — HMS Belfast (way, distance: 5.0 
> km)
> Q55019 — Covent Garden — Royal Opera House (way, distance: 71 m)
> Q607700 — Monument to the Great Fire of London — Tower Bridge (node,
> distance: 1.4 km)
> Q5571009 — Globe Theatre (Newcastle Street) — Shakespeare's Globe
> (relation, distance: 2.5 km)
>   - note that this one confuses the historic with the modern
> theatre of the same name. The modern one has a separate wkp page.
> Q43279 — Wembley Stadium (1923) — Wembley Stadium (way, distance: 0 m)
>   - again the correct connection should be with the modern stadium
> Q3527632 — Dorset Garden Theatre — Queen's (way, distance: 2.8 km)
>   - another historic thing (Dorset Garden was called Queen's at one point)

Thanks I'll investigate these. I'm going to add more debugging to the output,
so we can see the names that matched.

-- 
Edward.

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

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

On Mon, Jan 25, 2016 at 4:27 PM, Glenn Plas  wrote:
>> which means we could plan a face-to-face meeting in 2 months ?
>
> For me it's ok to do this sooner, I really don't want to wait another 2
> months to start on this, summer is coming and this is going to keep me
> inside :)

fine for me, we could even do this while the discussion on the import
mailing list is going on, not ?
This means that we should start looking for a meeting place and a
date. And we should know who is going to be involved (or wants to be
involved)

m

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

Re: [OSM-co] Mapeado cerca de la U Javeriana de Bogotá

[hyan...@gmail.com]

El 24 de enero de 2016, 15:36, Andres Gomez Casanova 
escribió:

> intentar contactar al profesor de la asignatura para que estos cursos de
> mapeo no sean solo para estudiantes sino para la comunidad.
>
>
OK, me parece la iniciativa correcta ¿talvez una mapatón del centro de
Bogotá (Teusaquillo - La Candelaria) en La Javeriana? ¿Cual sería la vía
para contactar al profesor?
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk-fr] live.openstreetmap.fr

[Laurent Combe]

oui le drapeau ce n'est pas vital mais dans l'imaginaire ça montre bien
qu'osm est international

christian : merci pour les marqueurs

Le 24 janvier 2016 à 17:55, Philippe Verdy  a écrit :

> Je veux dire que je vois la carte et les marqueurs, les noms des
> contributeurs, en revanche le drapeau du pays est juste blanc (ça n'a pas
> grande importance à mon avis, la géolocalisation des contributeurs est
> hasardeuse, intrusive si basée sur l'IP, ou souvent renseignée manuellement
> selon les zones d'intérêt du moment)
>
> Le 24 janvier 2016 à 17:22, Laurent Combe  a écrit
> :
>
>> Bonjour
>>
>> j'apprécie la page live.openstreetmap.fr
>> elle me sert quand je parle d'osm autour de moi
>>
>> par contre deux petits détails
>> les lieux de modifications ne font plus apparaitre de "marker" mais le
>> navigateur firefox affiche un symbole signifiant image non trouvée (c'est
>> moche)
>>
>> il y avait aussi un drapeau en face des contributeurs
>> maintenant les drapeaux ont disparu
>>
>> Peut-on rétablir le fonctionnement de live.openstreetmap.fr sur ces deux
>> points ?
>>
>> ___
>> 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: [Talk-us] State of the Map US bidders: join the virtual Town Hall!

[Alex Barth]

Reminder - the virtual townhall on State of the Map US is happening today
at 5PM ET! All the info to join is here:
https://openstreetmap.us/2016/01/sotmus-2016/

Spread the word + happy Monday everyone.

On Tue, Jan 19, 2016 at 8:14 PM, Alex Barth  wrote:

> Are you bidding / thinking of bidding for State of the Map US?
>
> We're holding a virtual Town Hall meeting to answer your questions on
> **Monday January 25th 5PM - 6PM Eastern** on Google Hangout.
>
> 1. RSVP on Google Hangout
> https://plus.google.com/u/1/events/c7venol7lhk5slsufpef1bbfddo
> 2. Simply join us at the time of the event by clicking the "Hangout" link
> here: https://plus.google.com/u/1/events/c7venol7lhk5slsufpef1bbfddo
>
> If you aren't able to connect through Google hangout, you can also ask
> questions on #osm-us on IRC http://wiki.openstreetmap.org/wiki/IRC during
> the time of the Town Hall.
>
> You can still submit a bid for State of the Map US until February 15th:
> https://openstreetmap.us/2016/01/sotmus-2016/
>
> Cheers!
>
> Alex
>
> --
> Alex Barth
> Vice President
> OpenStreetMap United States Inc.
>



-- 
Alex Barth
Vice President
OpenStreetMap United States Inc.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] Agiv import

[Marc Gemis]

A short question about source:geometry.

Should I/we keep it when we modify the building afterwards. I'm
thinking of the following cases

* In the meantime, part of the building got destroyed
* The building got finished in the meantime
* straighten the corners
* connecting 2 building parts because the part above the
"tunnel=building_passage" is missing
* splitting a building because the garage is clearly separated on AGIV imagery


regards

m

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

Re: [Talk-cz] Oprava vadne fotky rozcestniku?

[Marián Kyral]

Tak to napiš česky ;-)

Dle ref by to mělo být tady: http://www.openstreetmap.org/node/277635207

@wally: co takhle na api.openstreetmap.cz, jak tam jsou ty odkazy na
různé mapy, přidat osmap.cz?

Marián

Dne 25.1.2016 v 10:21 Petr Vozdecký napsal(a):
> ne 3 m ale 3 km!
>
> -- Původní zpráva --
> Od: Michal Grézl
> Datum: 24. 1. 2016 v 23:48:55
> Předmět: Re: [Talk-cz] Oprava vadne fotky rozcestniku?
>
> ja to presunu, kdyz reknes presne kam. presouvaci funkce bude az na
> novym osm.cz fakt 3 metry? to nema cenu ani resit, to je uplne v ramci
> chyby gps 2016-01-20 17:18 GMT+01:00 Petr Vozdecký : > Ahoj, > >
> nahodne jsem zaregistroval vadne umistenou fotku rozcestniku > > jde o
> http://api.openstreetmap.cz/table/id/4517 > > zrovna jsem jej sam pred
> par dny fotil, ale jednak je ho v systemu jen pulka > (druha je na
> druhe strane stromu) a soucasne plati, ze ma souradnice > umistene o
> 3.217 m vzdusnou carou jinde... > > Jak postupovat? Zatim jsem udelal
> to, ze jserm na vyse uvedenem URL editoval > pole poznamka a tam jsem
> to strucne uvedl... > > vop > >
> ___ > Talk-cz mailing list
> > Talk-cz@openstreetmap.org >
> https://lists.openstreetmap.org/listinfo/talk-cz > -- Michal Grézl
> http://openstreetmap.cz
> ___ Talk-cz mailing list
> Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [OSM-talk-fr] Problème de langue

[David Crochet]

Le 25/01/2016 19:09, David Crochet a écrit :

Bonjour

En faite il faut une relation-mère de type route, composé de
relation-filles de type route limité aux limites administratives, etc.
pour finir avec des relations de type route locales.

Cordialement



exemple : http://www.openstreetmap.org/relation/2521076 (car contre 
cette relation ne porte pas le bon nom car son nom officiel est « 
Central Europe Route » ).


Cordialement

--
David Crochet

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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

Hi Marc,

On 25-01-16 17:05, Marc Gemis wrote:
> A short question about source:geometry.

Feel free to ask

> 
> Should I/we keep it when we modify the building afterwards. I'm
> thinking of the following cases

When I modified a building manually because GRB is not correct, I change
this to source:geometry=AGIV

This way it would be a very simple/lightweight Overpass query to see the
manually adjusted buildings.  This could even serve as a feedback to GRB
itself, as I hate finding errors and mistakes in GRB with no (easy and
fast) way to reporting this.

It's also easy to extend this, source *could* be Bing (although I hope
to never see that in the data), it could be a future source, but any
adjustment made, I would strongly recommend changing that value.  It
could probably be 'Survey' in your case ;-)

The most common error is when only the front side has been measured and
the visible sides (aka , what you can see from standing in the street)

> * In the meantime, part of the building got destroyed
> * The building got finished in the meantime
> * straighten the corners
> * connecting 2 building parts because the part above the
> "tunnel=building_passage" is missing

building passages are actually in the GRB-Gis dataset, often, but not
always it's a 'verdieping' or 'roof'.  I've seen both with a lot more
verdieping's than roofs for building passages.

> * splitting a building because the garage is clearly separated on AGIV imagery

You should not have to do that imho, I've never encountered this 'too
much building in between' situation.  When the garage is separated
visibly on sat images but not in GRB, that's a precarious case, it could
be that the building has been replaced but GRB isn't up to date, it
could also be that the sat pics used are out of date and there has been
an additional construction already in GRB.  You can't tell now what is
correct from combining al sources of information.

If you want to be complete on buildings, you have to combine at least 3
shape files:

Gbg = main buildings and buildings (OSM types: sheds, garages, house,
churches, hangars, office and so on ...)

Adp = roofs, verdieping (in essence a building), difference between roof
attached(overhang on building) and separate (a free standing gas station
roof)

Knw = So far what I've seen, none of these buildings have a
housenumber/address/street attached. Most often, these buildings are
separated from the rest , but I've seen some that attached to other
buildings.

Knw is the hardest to turn into OSM with a script in fact, I still need
to implement this.  But the amount of buildings in here is small and
none are sporting an address in the datasets I analysed, I find these
less important at this moment.

But combined, they should match the building you see well. Make sure you
compare your building with at least the combined Gbg+Adp GRB version.

But 'too much building'-case in between , I only encountered this when
buildings were obviously destroyed.  Resulting in deleting in entirely.

Do you have an OIDN (and area) of this building? I can take a look at
the data set to understand better.

Glenn


See http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB

> 
> 
> regards
> 
> 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

Re: [OSM-talk-fr] Problème de langue

[David Crochet]

Bonjour

En faite il faut une relation-mère de type route, composé de 
relation-filles de type route limité aux limites administratives, etc. 
pour finir avec des relations de type route locales.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Problème de langue

[rainerU]

Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>   name=European route E 54

Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
le signalement Osmose et cela ne correspond à aucune réalité, car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
anglais. La solution qui refléterait le mieux la réalité serait de ne
pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 54".

Le plus simple serait de faire comme pour d'autres routes du même type,
c'est à dire de supprimer tous les attributs name. Si on veut on peut
toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







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

[OSM-talk-fr] faire passer voie ferrée sur pont

[lenny.libre]

Bonjour
J'ai mis à jour deux chemins qui passent sous sous un pont emprunté par 
une voie ferrée :

http://www.openstreetmap.org/way/392570058
http://www.openstreetmap.org/way/392570064

En fait, j'ai indiqué qu'ils passaient dans un tunnel, alors qu'ils 
passent sous un pont sur lequel circulent les voies ferrées :

http://www.openstreetmap.org/way/290368896
http://www.openstreetmap.org/way/225327281
Mais lorsque j'insère des point et que je partage les chemins pour 
ajouter sur la portion bridge=yes, josm m'envoie l'avertissement suivant :




Comment faut-il faire pour créer un pont sans perturber le réseau ferré 
existant ?


merci d'avance
Lenny
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de langue

[Gautier Pelloux-Prayer]

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les Alpes : 
http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, mais 
en même temps je vois pas de bonne solution pour qu'il le soit en 
l'état... ? La solution de ne pas avoir de nom du tout serait pour moi 
la plus logique, mais osmose ne sera toujours pas satisfait il me semble.


Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54

Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
le signalement Osmose et cela ne correspond à aucune réalité, car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
anglais. La solution qui refléterait le mieux la réalité serait de ne
pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 54".

Le plus simple serait de faire comme pour d'autres routes du même type,
c'est à dire de supprimer tous les attributs name. Si on veut on peut
toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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-GB] Next UK chapter concall

[Brian Prangle]

Hi everyone

Don't forget this is scheduled for 8pm Wed this week 27 January

0800 22 90 900  Pass code 33224

We'll pick up on Rob's summary email i.e objectives;legal stucture;
constitution

If we can I'd like to start discussing:

Name (not what it will be - but a mechanism for choosing one)
Membership classes, rights and costs

On objectives:the ensuing silence since draft 2 I'm not sure to take as
indifference or approval, but let's use the text as a starting point:

1.To increase the size, skills, toolsets and cohesion of the OpenStreetMap
community in the UK.

2.To promote and facilitate the use of OpenStreetMap data by organisations
in the UK.
3.To promote and facilitate the release by organisations in the UK of
OpenData  that is suitable for use in OpenStreetMap.

On legal structures, please read Rob's excellent summary before the
concall. I've read it and my conclusion so far, and I'm still not clear on
some things, is that we shouldn't go for unincorporated society (unlimited
liablity for officers) or charity (we don't have a charitable purpose and
the legal strictures are a bit more complex than we'd want). From the rest
I think company limited by guarantee (that's what OSMF chose) suits us
best. Not sure yet whether CIO or CIC, given that we'd be non-profit, are
worth considering.

Look forward to "seeing" you Wed

Regards

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

Re: [OSM-talk-fr] live.openstreetmap.fr

[Philippe Verdy]

Je pense aussi que ces drapeaux demandent des informations sur
l'utilisateur dans la base de données, et que c'est aussi une perte de
temps en requêtes, il y a bien assez de données à récupérer mais celle-là
on peut s'en passer

D'autant que ça surcharge vite le navigateur et ralentit l'affichage (quand
la page se met à jour à chaque seconde, ça fait vite des milliers de
requêtes en quelques heures). Laissez tourner le live pendant une heure et
voyez la mémoire prise par le navigateur, ça explose assez vite en version
32 bits quand l'historique est bien chargé.

De ce côté-là, il y a peut-être moyen d'optimiser la place prise pour les
objets conservés dans l'historique, quitte à recharger les détails
seulement à la demande quand on sélectionne une des modifs, et en garder le
moins posisble pour n'avoir que la liste, il suffirait de ne garder que la
le nom d'utilisateur, l'horodatage en format le plus compact possible, et
le numéro de changeset pour pouvoir réafficher les détails à la demande (y
compris l'ID d'utilisateur donnant sa géolocalisation, ou la bounding box
permettant de réafficher la carte). LE reste utilisé seulement de façon
temporaire pour n'afficher que la vue actuelle, et jeté quand on passe à la
vue suivante.

Je n'ai pas regardé dans les détails mais il semble bien que l'historique
soit moins volumineux maintenant et que ça explose moins vite en mémoire
(surtout dans un navigateur 32 bits, même sur les OS 64 bits; sur un OS 32
bits, et notamment sur pas mal de tablettes, cela explose plus vite car la
mémoire limitée est aussi à partager avec les autres onglets utilisés pour
la navigation sur d'autres sites et pour d'autres applications
concurrentes: le processus ou les processus du navigateur sont restreints,
on ne peut pas tout faire en données javascript sinon ça se met à ramer dur
malgré les efforts du garbage collector). Pour le reste même si on ne
conserve pas les données en mémoire, cela ne provoquera pas beaucoup plus
de requêtes au serveur si les données obtenues sont cachables dans le cache
disque du navigateur.

L'idéal étant de pouvoir faire tourner facilement le live pendant quelques
heures en continu, cela devrait pouvoir stocker un historique de plusieurs
milliers de lignes (changesets). Au pire, ne garder en mémoire historique
que des numéros de changeset, et uniquement en mémoire le détail des lignes
qui sont sur les lignes visibles de l'historique ou une page ou deux avant
et après (en mode pause), le reste étant fait avec des requêtes serveur via
le cache du navigateur.

Idée à creuser... Mais je pense que l'auteur de l'outil a dû déjà chercher
car ça s'est amélioré.



Le 25 janvier 2016 à 16:52, Laurent Combe  a écrit :

> oui le drapeau ce n'est pas vital mais dans l'imaginaire ça montre bien
> qu'osm est international
>
> christian : merci pour les marqueurs
>
> Le 24 janvier 2016 à 17:55, Philippe Verdy  a écrit :
>
>> Je veux dire que je vois la carte et les marqueurs, les noms des
>> contributeurs, en revanche le drapeau du pays est juste blanc (ça n'a pas
>> grande importance à mon avis, la géolocalisation des contributeurs est
>> hasardeuse, intrusive si basée sur l'IP, ou souvent renseignée manuellement
>> selon les zones d'intérêt du moment)
>>
>> Le 24 janvier 2016 à 17:22, Laurent Combe  a
>> écrit :
>>
>>> Bonjour
>>>
>>> j'apprécie la page live.openstreetmap.fr
>>> elle me sert quand je parle d'osm autour de moi
>>>
>>> par contre deux petits détails
>>> les lieux de modifications ne font plus apparaitre de "marker" mais le
>>> navigateur firefox affiche un symbole signifiant image non trouvée (c'est
>>> moche)
>>>
>>> il y avait aussi un drapeau en face des contributeurs
>>> maintenant les drapeaux ont disparu
>>>
>>> Peut-on rétablir le fonctionnement de live.openstreetmap.fr sur ces
>>> deux points ?
>>>
>>> ___
>>> 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: [Talk-us] Fwd: State Park Boundary shp file

[Paul Johnson]

On Sat, Jan 23, 2016 at 5:30 PM, Ian Butler  wrote:

> Another possibility for state park boundary shp files might be the
> Oklahoma Protected Areas Database at the Oklahoma Biological Survey.
> I have not seen this data; but I worked on the original public lands layer
> for the Oklahoma GAP project.
>
> http://biosurvey.ou.edu/PAD/PAD.html
>
> "PAD-OK is an aggregated dataset, incorporating data as provided by land
> owners, administrators, or best available sources.
> Inconsistencies in data quality and scale may be present. Because of
> possible data inconsistencies, PAD-OK is best for landscape
> level analysis (1:100,000 or greater)..."
>

Excellent!  I'm able to read this.  It's not *quite* in alignment, but it's
close enough that I can conflate it easily on a case by case basis.  But,
looking at
http://www.ou.edu/content/publicaffairs/webpolicies/termsofuse.html, I'm
wondering if this is even a dataset that we can use, or if it's just
typical boilerplate that is nullified by the Open Records Act.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Problème de langue

[Gautier Pelloux-Prayer]

Non, je ne crois pas : 
http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==


La langue anglaise est bien dans la liste, mais au moins 
osmose.openstreetmap.fr n'est pas content. Ou alors tu parles 
uniquement pour les highways...



Le lun. 25 janv. 2016 à 19:02, Philippe Verdy  a 
écrit :
Osmose est content quand au moins un des noms "name:lang=*" 
correspond à celui indiqué dans "name=*".


Bref renseigner un nom dans "name=*" (langue quelconque) et dans 
"name:fr=*"


Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer 
 a écrit :

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les 
Alpes : http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, 
mais en même temps je vois pas de bonne solution pour qu'il le soit 
en l'état... ? La solution de ne pas avoir de nom du tout serait 
pour moi la plus logique, mais osmose ne sera toujours pas satisfait 
il me semble.



Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54
Pour moi, ce n'est pas la bonne solution. Cela ne fera pas 
disparaître
le signalement Osmose et cela ne correspond à aucune réalité, 
car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas 
de nom
anglais. La solution qui refléterait le mieux la réalité serait 
de ne

pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 
54".


Le plus simple serait de faire comme pour d'autres routes du même 
type,
c'est à dire de supprimer tous les attributs name. Si on veut on 
peut

toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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] Problème de langue

[Philippe Verdy]

Osmose est content quand au moins un des noms "name:lang=*" correspond à
celui indiqué dans "name=*".

Bref renseigner un nom dans "name=*" (langue quelconque) et dans "name:fr=*"

Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer  a
écrit :

> Bonjour,
>
> Si cela peut aider au débat, il y a le "même" problème pour les Alpes :
> http://www.openstreetmap.org/relation/2698607
>
> Osmose n'est pas content car on utilise par défaut le nom Anglais, mais en
> même temps je vois pas de bonne solution pour qu'il le soit en l'état... ?
> La solution de ne pas avoir de nom du tout serait pour moi la plus logique,
> mais osmose ne sera toujours pas satisfait il me semble.
>
>
> Le 25/01/2016 18:37, rainerU a écrit :
>
>> Am 25.01.2016 um 13:04 schrieb Dominique Faure:
>>
>>>name=European route E 54
>>>
>> Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
>> le signalement Osmose et cela ne correspond à aucune réalité, car c'est
>> une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
>> anglais. La solution qui refléterait le mieux la réalité serait de ne
>> pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
>> faut absolument un attribut name=* il faut couper la relation en une
>> partie française et une partie allemande et les regrouper dans une
>> relation qui aura comme nom "Route européenne 54 / Europastraße 54".
>>
>> Le plus simple serait de faire comme pour d'autres routes du même type,
>> c'est à dire de supprimer tous les attributs name. Si on veut on peut
>> toujours construire un nom à partir des tags network et ref :
>>
>> https://www.openstreetmap.org/relation/2148632
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] faire passer voie ferrée sur pont

[David Crochet]

Bonjour

Le 25/01/2016 18:42, lenny.libre a écrit :

josm m'envoie l'avertissement suivant :



Ce n'est qu'un avertissement. Ce n'est nullement lié à tes modifications 
de tes deux chemins, mais comme en modifiant une zone JOSM à téléchargé 
la voies ferrée, il t'annonce les avertissements de ce qu'il à chargé. 
Donc laisse JOSM te dire cela pour les voies ferrée.



Cordialement
--
David Crochet

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

Re: [OSM-talk-be] Tourniquet à vache

[Matthieu Gaillet]

Wow ! J’aurais dû aller vérifier le wiki avant ! Pour ma part turnstile me 
semble être le plus adapté, l’aspect rotatif de l’engin me semble déterminant 
ici. Merci !


> On 25 Jan 2016, at 22:01, lionel bulpa  wrote:
> 
> Bonsoir,
> 
> Je crois que tu peux l'inscrire en barrier=turnstile ou barrier=stile mais le 
> plus approprié me semble être barrier=kissing_gate puisque cela concerne le 
> bétail. Tu peux aller consulter le Wiki 
> http://wiki.openstreetmap.org/wiki/Key:barrier 
> 
> 
> Lio
> 
> > From: mgwebm...@fastmail.fm 
> > Date: Mon, 25 Jan 2016 21:51:19 +0100
> > To: talk-be@openstreetmap.org 
> > Subject: [OSM-talk-be] Tourniquet à vache
> > 
> > 
> > Hi again,
> > 
> > How would you tag the “tourniquet à vache” those rotating barriers that 
> > allows a walker to get through the fence but not a cow ? Picture here : 
> > http://www.balnam.be./photos/223151.jpg
> > 
> > I received a nice dataset for wallonie from Itinéraires Wallonie asbl that 
> > collected and geotagged most of them and took pictures, I’ll be happy to 
> > import them in OSM (with their authorisation of course).
> > 
> > Matthieu
> > 
> > PS/ Is it a Belgian specific thing ? I never saw this elsewhere.
> > ___
> > 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] Problème de langue

[Jérôme Seigneuret]

Bonjour,

J'appui Jean-Yvon pour le name

Coté relation David à raison sur le fait de gérer des relations avec des
niveaux multiples ce qui permet d'importer des portions ou de gérer des
itinéraires logiques par étapes avec les différents niveau (local,
régional, national...) d'où l'utilisation du name anglais sur une
super-relation (en Europe quand ça traverse les frontières)

Pour le check d'OSM c'est pas trivial sur le test du nom.

Je reprends le cas de Philippe
*Noms dans la langue locale et dans la langue par défaut différents*
*way 83115947 * rawedit
 josm
 edit

*highway* = living_street
*maxspeed* = 20
*name* = Chemin des Bauches
*name:fr* = Lotissement le Manoir

Là on n'est vraiment pas sur une question de langue mais sur une
incohérence de nom. C'est pas la traduction qui est testé mais juste une
correspondance entre le territoire le name:[langue] et le name

Le name ne donne pas d'information sur le territoire, hors la notion de
territoire est multi-échelle, multi-zonales comme celle des langues et ça
sans forcément de chevauchement. Si l'on prends la zone euro il n'y a pas
de langue officielle donc par défaut on prend la langue internationale qui
est l'anglais faute de mieux car l'espéranto n'a jamais percé.

Quand un objet se limite à un pays on prend en name sa langue officielle.
Quand l'objet traverse les territoires comme c'est le cas de certaines
relations, découper la relation pour avoir un affichage correspondant au
contexte du pays concerné et une au contexte global.

Jérôme



Le 25 janvier 2016 à 21:42,  a écrit :

> Quitte à remettre une couche : je ne suis pas un fana des duplications
> d'informations qui sont déjà là.
> Le E de E 54 veut dire route Européenne, European route, Europastrasse,...
> et a priori seule la référence figure sur le terrain :
> 
> https://fr.wikipedia.org/wiki/Route_europ%C3%A9enne_50#/media/File:RouteE50.JPG
>
> Il n'apporte donc rien. D'autant que le Wikidata donne les infos
> complémentaires si besoin (peut-être qu'Omose pourrait regarder la
> cohérence avec les Wikidata).
> On ne met pas non plus "route Nationale 19" pour la N19.
> Si on prend les EuroVélo, il est remarquable que sur le site ils utilisent
> par exemple EuroVelo 4.
>
> Plus important : la relation est cassée (en plusieurs morceaux) :
> 
> http://www.openstreetmap.org/relation/77040#map=17/47.63617/6.83655
>
> Pour ref=N 19, on ne met pas Route nationale non plus.
> Heu, a priori Christian a trouvé un endroit ou la N19 s'appelle Route
> nationale 19 : 
> http://www.openstreetmap.org/way/22729626.
> Mais est-utilisé sur le terrain ? Je vois un arrêt de bus "Santeny RN".
>
> Jean-Yvon
>
>
> Le 25/01/2016 13:04, Dominique Faure - dominique.fa...@gmail.com a écrit :
>
> Ok, j'ai renommé le trajet en anglais:
>
>   name=European route E 54
>
> et profité pour corriger quelques sens de circulation.
>
> Merci.
>
>
>
> 2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret :
>
>> Bonjour,
>>
>> J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
>> de modification. A moins de mettre le tag name en Anglais...
>>
>> Car cette alerte est à mon avis seulement valable pour les objets (node,
>> way, relation) se limitant à un territoire dont la langue est identifié
>> dans notre cas fr et non à des superpostion entre territoires
>>
>> Dans ton cas, la relation dépasse les frontières. Donc que choisir dans
>> ce cas... Le name en Anglais, le name du pays de départ (qui soit disant
>> passant est différent suivant le sens).
>>
>> J'aurais choisi un nom FR pour les tronçons en France un nom Allemand
>> pour les tronçons Allemand et pour la relation (Euro), le nom en anglais et
>> name:fr=* name:de=*
>>
>> le name:fr permet de toute manière de trouver cette relation dans
>> Nominatim
>>
>> Jérôme
>>
>> Le 25 janvier 2016 à 10:40, Dominique Faure < 
>> dominique.fa...@gmail.com> a écrit :
>>
>>> Bonjour,
>>>
>>> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
>>> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
>>> je sèche un peu...
>>>
>>> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
>>> lui redonner son nom et y rattacher quelques bâtiments dans une relation
>>> associatedStreet.
>>>
>>> Depuis cette modification, j'ai ce message d'erreur dans osmose (
>>> 
>>> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>>>
>>> =8<- - - - -
>>> Noms dans la langue locale et dans la langue par défaut 

[OSM-talk-be] Tourniquet à vache

[Matthieu Gaillet]

Hi again,

How would you tag the “tourniquet à vache” those rotating barriers that allows 
a walker to get through the fence but not a cow ? Picture here : 
http://www.balnam.be./photos/223151.jpg

I received a nice dataset for wallonie from Itinéraires Wallonie asbl that 
collected and geotagged most of them and took pictures, I’ll be happy to import 
them in OSM (with their authorisation of course).

Matthieu

PS/ Is it a Belgian specific thing ? I never saw this elsewhere.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-de] Forschungsstation Antarktis

[malenki]

On Mon, 25 Jan 2016 14:16:36 +0100,
Markus wrote:

> Gibt es ein tolles Beispiel für Mikro-Kartografie?

Auch zu finden unter http://bestofosm.org/



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

Re: [Talk-us] Fwd: State Park Boundary shp file

[Paul Johnson]

I have received word back from Todd Fagin at the University of Oklahoma and
he says that yes, the data is in the public domain, though he would like
attribution on our contributors page (NBD, already done at
http://wiki.openstreetmap.org/wiki/Contributors#Oklahoma).  I'm not fully
ready to do a full import on it, though this does open me up to being able
to use this as part of the Wild Nights mapping project to get that ready
for our conbook as a test case around the Robber's Cave Wildlife Area and
Robber's Cave State Resort.

On Sat, Jan 23, 2016 at 5:30 PM, Ian Butler  wrote:

> Another possibility for state park boundary shp files might be the
> Oklahoma Protected Areas Database at the Oklahoma Biological Survey.
> I have not seen this data; but I worked on the original public lands layer
> for the Oklahoma GAP project.
>
> http://biosurvey.ou.edu/PAD/PAD.html
>
> "PAD-OK is an aggregated dataset, incorporating data as provided by land
> owners, administrators, or best available sources.
> Inconsistencies in data quality and scale may be present. Because of
> possible data inconsistencies, PAD-OK is best for landscape
> level analysis (1:100,000 or greater)..."
>
> Contact Todd Fagin: tfagin at ou dot edu for info.
>
> I hope this helps.
>
> Ian Butler
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Problème de langue

[osm . sanspourriel]

Quitte à remettre une couche : je ne suis pas un fana des duplications 
d'informations qui sont déjà là.
Le E de E 54 veut dire route Européenne, European route, 
Europastrasse,... et a priori seule la référence figure sur le terrain : 
https://fr.wikipedia.org/wiki/Route_europ%C3%A9enne_50#/media/File:RouteE50.JPG


Il n'apporte donc rien. D'autant que le Wikidata donne les infos 
complémentaires si besoin (peut-être qu'Omose pourrait regarder la 
cohérence avec les Wikidata).

On ne met pas non plus "route Nationale 19" pour la N19.
Si on prend les EuroVélo, il est remarquable que sur le site ils 
utilisent par exemple EuroVelo 4.


Plus important : la relation est cassée (en plusieurs morceaux) :
http://www.openstreetmap.org/relation/77040#map=17/47.63617/6.83655

Pour ref=N 19, on ne met pas Route nationale non plus.
Heu, a priori Christian a trouvé un endroit ou la N19 s'appelle Route 
nationale 19 : http://www.openstreetmap.org/way/22729626. 


Mais est-utilisé sur le terrain ? Je vois un arrêt de bus "Santeny RN".

Jean-Yvon

Le 25/01/2016 13:04, Dominique Faure - dominique.fa...@gmail.com a écrit :

Ok, j'ai renommé le trajet en anglais:

  name=European route E 54

et profité pour corriger quelques sens de circulation.

Merci.



2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret >:


Bonjour,

J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai
pas fait de modification. A moins de mettre le tag name en Anglais...

Car cette alerte est à mon avis seulement valable pour les objets
(node, way, relation) se limitant à un territoire dont la langue
est identifié dans notre cas fr et non à des superpostion entre
territoires

Dans ton cas, la relation dépasse les frontières. Donc que choisir
dans ce cas... Le name en Anglais, le name du pays de départ (qui
soit disant passant est différent suivant le sens).

J'aurais choisi un nom FR pour les tronçons en France un nom
Allemand pour les tronçons Allemand et pour la relation (Euro), le
nom en anglais et name:fr=* name:de=*

le name:fr permet de toute manière de trouver cette relation dans
Nominatim

Jérôme

Le 25 janvier 2016 à 10:40, Dominique Faure
> a
écrit :

Bonjour,

"Jeune" contributeur d'OSM pour son quartier et alentours,
j'ai pu me débrouiller par mes propres moyens jusqu'à
maintenant, mais là, j'avoue que je sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de
commune) pour lui redonner son nom et y rattacher quelques
bâtiments dans une relation associatedStreet.

Depuis cette modification, j'ai ce message d'erreur dans
osmose (http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -

​ A noter que ma modification à eu lieu ici:
http://www.openstreetmap.org/way/391928538


Merci d'avance pour vos éclaircissements.
-- 
Dominique


___
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




--
Dominique


___
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] Bicycle highways

[Matthieu Gaillet]

Hi, thanks all for your answers.

I agree with Jo and Sander : there is something missing in the current way of 
describing those bicycle highways which are indeed very specific in their 
realisation (exactly like a car highway) and their use (connecting cities). 

I don’t agree with Sander when talking about getting freed of the icn, ncn and 
rcn network tags : they are extremely widely used and useful for rendered like 
http://cycling.waymarkedtrails.org/  to 
render the relations accurately. I don’t really see your point here.

However, before talking about relation, I think a specific value should be 
introduced for the highway key : “cyclehighway" for instance. This would help 
the renderer to show those infrastructures differently than the usual 
“cycleway” (the infamous "piste cyclable” that usually sounds like an insult 
for most serious bikers).

This is however something that has to be discussed on a higher level than 
Belgium. Where is this place ?

Thanks for sharing your thoughts about this.

Matthieu


> On 24 Jan 2016, at 17:36, Jo  wrote:
> 
> Between Leuven and Brussels they are marked in a way that is verifiable on 
> the ground.
> 
> We need a separate 'network' tag for them though, and it would be nice to see 
> they get rendered on the specialised bicycle maps.
> 
> Jo
> 
> 2016-01-24 15:31 GMT+01:00 Sander Deryckere  >:
> Bicycle highways are more like bicycle routes than different highway types.
> 
> They are a route specifically made for commuting, connecting residential area 
> with some work center in a rather straight line.
> 
> As such, I think those could get tagged as a cycle route with some specific 
> sub tags (like a special network).
> 
> The question is though: are they verifiable on the ground. Or is it just that 
> European list naming them. It should only be tagged when you see something on 
> the ground that you can relate to bicycle highways.
> 
> Regards,
> Sander
> 
> 2016-01-24 15:00 GMT+01:00 Glenn Plas  >:
> Nothing really special about them,  highway=cycleway should be appropriate.
> 
> Glenn
> 
> On 24-01-16 13:12, Matthieu Gaillet wrote:
> > Hi,
> >
> > Below you will find some information about the developing bicycle
> > highways (or fast cycling routes) a bit everywhere in the world.
> >
> > I was wondering if anything was foreseen to tag such highways ? If not,
> > what's the best place to discuss this, since I guess this should be
> > uniform at world level ?
> >
> > Thanks for your answer,
> >
> > Matthieu (sur iMobile)
> >
> > Début du message transféré :
> >>
> >> Une recherche, évidemment loin d’être exhaustive, m’a fourni une
> >> première liste de ce que l’ECF (European Cyclists’ Federation) dénomme
> >> les  */Fast Cycling Routes/** :*
> >> •  CH: Velobahn (Schaffhouse), TransAgglo (Fribourg), .
> >> •  DE: Radschnellwege  (Ruhr, Berlin, Frankfurt, Heidelberg, München, …)
> >> •  DK: Supercykelstier (Kobenhavn)
> >> •  FR: REV, Réseau Express Vélo, Autoroute à vélos (Toulouse),
> >> Vélostras (Strasbourg), Grenoble, Paris,
> >> •  NL: SnelleFietsroutes, Snelbinder
> >> Image en ligne
> >> •  SV: Supercykelväg (Malmoe)
> >> •  UK: Cycle Superhighways (London)
> >> •  US: California Cycleway(1896)
> >> •  VL: Fietsostrades (réalisations ; projets dans les 5 provinces)
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be 
> > 
> >
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[Talk-de] TopPlus vom BKG

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hallo,

rein zufällig bin ich die Tage über TopPlus vom Bundesamt für
Kartographie und Geodäsie gestolpert. Das war hier im Mai 2014 schon
einmal Diskussionsthema:
https://lists.openstreetmap.org/pipermail/talk-de/2014-May/108204.html

Mittlerweile gibt es "TopPlus-Web-Refugees". [1]

Das richtet sich an "alle nichtkommerziellen Vorhaben von
Verwaltungsstellen des Bundes, der Länder, der Kommunen sowie von
Nicht-Regierungsorganisationen und Unternehmen bei der Bewältigung der
Flüchtlingslage". Es besteht nicht nur einem Kartendienst (daher der
Name), sondern hat auch einen Routingdienst und einen
deutschlandweiten Geocoding-Dienst.

Wie bisher wird außerhalb Deutschlands viel OSM für das Rendering
verwendet.

Für das Routing wird OSRM und OSM2PO eingesetzt. Auch innerhalb
Deutschlands wird OSM eingesetzt. Es Begründung wird dazu geschrieben
[2]:
> Datengrundlage des Dienstes sind die Datenbestände des OpenSource-
>  Projektes „OpenStreetMap“, da zum heutigen Zeitpunkt existierende
>  amtliche Geobasisdaten keine Routingdaten enthalten und somit
> nicht routingfähig sind.

Übrigens, den Kartenstil kann man sich auch im Web in einer Vorschau
bis auf die höchste Zoomstufe anschauen.

Viele Grüße

Michael


[1]
www.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=deu_akt_z
eile=4_anz_zeile=5_unt_zeile=0_user_id=0
[2] http://www.geodatenzentrum.de/docpdf/routingdienst.pdf


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWpovDAAoJEB87G9rMCMyI8hIP/2zI5zTQ6VnNH7MThhtE47Wc
NTzbQOVPPCImglINLLyCG5pIldCwHQcKXUY9GhHjkbExuVV1qKTq03PuMcZfCA8P
SOd5Ef5zcepb++q6bxAolNoIc52bEpeWHBczVG30a7qAQiUtIf/YEicGIFzbFqLu
Fj+uiyEMAWs3G3+pgARUCdlsNWIe3PdGRD8EoureqOA2dt3s/YTpGM4exiZjTQkB
ccNfVSwGx/rXkDCa0sbnJqpNRtGG15w0MYsi07twh+NfStGNkVQ0hc7iowLwmaPR
G2NBKDeArexTPRt/LnBzP0dudxFuTgZvb0NmnP1Tbblx3xWCvkAkegYpHV880QBM
brS55NTUEc+qTxmjTqLYELvxBfABXliDVzT8/O9GAgvCYCRznWjZI30oskSioP4Y
0EJV+qQzfN+piQ+OT+uam7k/pKDvkZ0g4WOPbTw1ClWwpTqK+l5z49rODmhUAYIT
tDTMXWhdTjJNBeI1diZtBltnwhzc+XFFGcpI40zWHrF8rrSFdJFwcfzEqLp+LQZl
J+dLyL44ydrpgsKWrMun3ysdpXmSX8cwn73LIeKpphMGXvxhDSAXHRZYhH+QsUDN
uJObOTD5X2m76pJBQQNozQefJ3V1tEyYf+Sbja7OBLwiRH+R85QXWBHYag3jO61Q
OkrbHDZip6dMoRw+XN9J
=NEmr
-END PGP SIGNATURE-

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

Re: [OSM-talk-be] Tourniquet à vache

[lionel bulpa]

Bonsoir,
Je crois que tu peux l'inscrire en barrier=turnstile ou barrier=stile mais le 
plus approprié me semble être barrier=kissing_gate puisque cela concerne le 
bétail. Tu peux aller consulter le Wiki 
http://wiki.openstreetmap.org/wiki/Key:barrier
Lio

> From: mgwebm...@fastmail.fm
> Date: Mon, 25 Jan 2016 21:51:19 +0100
> To: talk-be@openstreetmap.org
> Subject: [OSM-talk-be] Tourniquet à vache
> 
>   
> Hi again,
> 
> How would you tag the “tourniquet à vache” those rotating barriers that 
> allows a walker to get through the fence but not a cow ? Picture here : 
> http://www.balnam.be./photos/223151.jpg
> 
> I received a nice dataset for wallonie from Itinéraires Wallonie asbl that 
> collected and geotagged most of them and took pictures, I’ll be happy to 
> import them in OSM (with their authorisation of course).
> 
> Matthieu
> 
> PS/ Is it a Belgian specific thing ? I never saw this elsewhere.
> ___
> 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] Fwd: State Park Boundary shp file

[Clifford Snow]

On Mon, Jan 25, 2016 at 9:39 AM, Paul Johnson  wrote:

> Excellent!  I'm able to read this.  It's not *quite* in alignment, but
> it's close enough that I can conflate it easily on a case by case basis.
> But, looking at
> http://www.ou.edu/content/publicaffairs/webpolicies/termsofuse.html, I'm
> wondering if this is even a dataset that we can use, or if it's just
> typical boilerplate that is nullified by the Open Records Act.
>

The section under copyright (below) seems to exclude use by OSM. It does
seem to be generic boilerplate to the site so they may give permission to
use the boundaries in OSM. I would recommend contacting them for permission.

*Copyright.* The content, organization, graphics, design, compilation,
magnetic translation, digital conversion and other matters related to the
Site are protected under applicable copyrights, trademarks and other
proprietary (including but not limited to intellectual property) rights.
The commercial copying, redistribution, use or publication by you of any
such matters or any part of the Site is strictly prohibited. You do not
acquire ownership rights to any content, document or other materials viewed
through the Site. The posting of information or materials on the Site does
not constitute a waiver of any right in such information and materials.

All Web sites and electronic publications must follow University and legal
standards regarding copyright. In general, Web publishers must secure
permission from the owner of the copyright when including copyrighted or
trademarked material, such as text, photographs, audio, video, graphics,
maps, or logos, and include a permission statement or disclaimer as
required by the owner of the copyright or trademark. Provisions of fair use
can allow restricted use of copyrighted materials without permission of the
copyright holder. The TEACH Act provides some extensions of fair use for
distance education. For more information on copyright, see the U.S.
Copyright Office Web site at www.copyright.gov.


Clifford

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

Re: [Talk-de] Forschungsstation Antarktis

[Christian Pietzsch]

Damit kann man ganz gut Stationen in der Artkis finden:
http://overpass-turbo.eu/s/dYJ
Die Station von letztens, sollte diese hier sein:
http://www.openstreetmap.org/#map=16/-67.5692/-68.1251

Gutes Beispiel für Micro_mapping ist Roßleben:
http://bestofosm.org/#best-of-de-rossleben
oder Hundkot-Tüten-Spender: http://overpass-turbo.eu/s/dYM

3D gibt es sicher einiges schönes: Ich nehme einfach mal Dresden ;)
http://demo.f4map.com/#lat=51.0541284=13.7365253=18=60.756=-136.26

Am 25. Januar 2016 um 14:16 schrieb Markus :

> Da war neulich ein Link
> zu einer toll kartografierten Forschungsstation in der Antarktis...
>
> Wer kann mir damit helfen?
>
> Gibt es ein tolles Beispiel für Mikro-Kartografie?
>
> und für 3D?
>
> Mit herzlichem Gruss,
> Markus
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-us] Fwd: State Park Boundary shp file

[Paul Johnson]

Todd Fagin at OU did confirm this mintues ago, we're good to go.

On Mon, Jan 25, 2016 at 3:57 PM, Clifford Snow 
wrote:

>
> On Mon, Jan 25, 2016 at 9:39 AM, Paul Johnson  wrote:
>
>> Excellent!  I'm able to read this.  It's not *quite* in alignment, but
>> it's close enough that I can conflate it easily on a case by case basis.
>> But, looking at
>> http://www.ou.edu/content/publicaffairs/webpolicies/termsofuse.html, I'm
>> wondering if this is even a dataset that we can use, or if it's just
>> typical boilerplate that is nullified by the Open Records Act.
>>
>
> The section under copyright (below) seems to exclude use by OSM. It does
> seem to be generic boilerplate to the site so they may give permission to
> use the boundaries in OSM. I would recommend contacting them for permission.
>
> *Copyright.* The content, organization, graphics, design, compilation,
> magnetic translation, digital conversion and other matters related to the
> Site are protected under applicable copyrights, trademarks and other
> proprietary (including but not limited to intellectual property) rights.
> The commercial copying, redistribution, use or publication by you of any
> such matters or any part of the Site is strictly prohibited. You do not
> acquire ownership rights to any content, document or other materials viewed
> through the Site. The posting of information or materials on the Site does
> not constitute a waiver of any right in such information and materials.
>
> All Web sites and electronic publications must follow University and legal
> standards regarding copyright. In general, Web publishers must secure
> permission from the owner of the copyright when including copyrighted or
> trademarked material, such as text, photographs, audio, video, graphics,
> maps, or logos, and include a permission statement or disclaimer as
> required by the owner of the copyright or trademark. Provisions of fair use
> can allow restricted use of copyrighted materials without permission of the
> copyright holder. The TEACH Act provides some extensions of fair use for
> distance education. For more information on copyright, see the U.S.
> Copyright Office Web site at www.copyright.gov.
>
>
> Clifford
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Problème de langue

[osm . sanspourriel]

Un autre intérêt d'avoir plusieurs niveaux dans les relations c'est de 
limiter les risques de trous.
Si la zone est suffisamment petite il y a des chances que les 
contributeurs chargent toute la relation et voient donc si elle est cassée.
Si on oublie un pays par exemple sur une route européenne, ça se verra 
facilement.
De plus si quelqu'un casse une relation la restaurer sera plus simple 
par un contributeur ordinaire.


Jean-Yvon


Le 25/01/2016 22:41, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit :

Bonjour,

J'appui Jean-Yvon pour le name

Coté relation David à raison sur le fait de gérer des relations avec 
des niveaux multiples ce qui permet d'importer des portions ou de 
gérer des itinéraires logiques par étapes avec les différents niveau 
(local, régional, national...) d'où l'utilisation du name anglais sur 
une super-relation (en Europe quand ça traverse les frontières)


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

Re: [Talk-us] State Park Boundary shp file

[Ian Butler]

I’m pleased this has worked out, and I’m looking forward to seeing the results 
down the road.

Ian

> On Jan 25, 2016, at 3:58 PM, Paul Johnson  wrote:
> 
> I have received word back from Todd Fagin at the University of Oklahoma and 
> he says that yes, the data is in the public domain, though he would like 
> attribution on our contributors page (NBD, already done at 
> http://wiki.openstreetmap.org/wiki/Contributors#Oklahoma).  I'm not fully 
> ready to do a full import on it, though this does open me up to being able to 
> use this as part of the Wild Nights mapping project to get that ready for our 
> conbook as a test case around the Robber's Cave Wildlife Area and Robber's 
> Cave State Resort.
> 
> On Sat, Jan 23, 2016 at 5:30 PM, Ian Butler  wrote:
> Another possibility for state park boundary shp files might be the Oklahoma 
> Protected Areas Database at the Oklahoma Biological Survey.
> I have not seen this data; but I worked on the original public lands layer 
> for the Oklahoma GAP project.
> 
> http://biosurvey.ou.edu/PAD/PAD.html
> 
> "PAD-OK is an aggregated dataset, incorporating data as provided by land 
> owners, administrators, or best available sources.
> Inconsistencies in data quality and scale may be present. Because of possible 
> data inconsistencies, PAD-OK is best for landscape
> level analysis (1:100,000 or greater)..."
> 
> Contact Todd Fagin: tfagin at ou dot edu for info.
> 
> I hope this helps.
> 
> Ian Butler
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
> 


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

[Talk-cz] Tracer LPIS - drobne relikty puvodnich drive vymapovanych poli a luk po pretrasovani podle LPIS

[Pavel Bokr]

Ahoj,

Predem se omlouvam pokud se ptam na neco co uz bylo receno, diskuze k trasovani 
LPIS je na me velmi obsahla a s odstupem casu uz dosti neprehledna.



V okoli meho mestecka (Kraluv Dvur) a nasledne i v sirsim okoli Berouna jsem od 
roku 2011 “rucne” mapoval mimo jine i landuse vcetne poli a luk (z pocatku 
podle UHULu, pozdeji snad byl nekde i Bing). Tohle jsem udelal na uzemi cca 
20x20 km, ukazku jak asi vypadal vysledek v mape jsem si ulozil jen pro me 
mesto [1]. Jo kdyby tehdy byl tracer ... 

Pak prisel Tracer LPIS. Sam jsem s nim zkousel trasovat pole nekde na 
Rokycansku - tam kde tyto plochy zatim zmapovany nebyly a byly tam tedy “bila 
mista” (to jeste tracer toho asi jeste neumel tolik co dnes). Do toho co uz 
jsem mel na Berounsku rucne zmapovane jsem se nepoustel ani jsem o tom radeji 
zatim neuvazoval.



Postupne si ale vsimam, ze k pretrasovani puvodnich rucne mapovanych ploch 
misty dochazi. Problem podle me vznika tam kde polygon dle LPIS je mensi nez 
puvodni a vznikne tak relikt – kolem velkeho pole jsou male prouzky pole, 
pripadne pokud se zmeni kultura (coz je klidne mozne, podle UHULu nebylo 
rozhodovani uplne jednoznacne) tak po okrajich louky jsou misty prouzky 
puvodniho pole. Screenshot z JOSM viz [2], odkaz na zivou mapu viz [3] – 
koukejte po okrajich pole a louky

Jeste nez se toto pripadne jeste vice rozsiri tak bych rad vznesl dotaz jestli 
je nejaky idealne snadno nalezitelny navod (nejlepe na wiki co by bylo snadno, 
rychle a bez sloziteho prohledavani pristupne uzivatelum LPIS traceru, kteri 
chteji zkusit pretrasovavat) jak tomuto predejit nebo jak nejlepe pracovat s 
LPIS tracerem v jiz zmapovane oblasti?




Vsiml jsem si ze se tracer stale vylepsuje (a diky moc za to!!!) a pak jde o to 
aby byl vhodne pouzivan s tim vsim co ted umi (ja osobne se priznam ze jsem 
zatim pretrasovani dle LPIS nezkousel). Pokud by se ale opakovane 
pretrasovavalo jako na uvedenych ukazkach, tak by nam vznikali v mape relikty a 
to asi neni dobre (i kdyz se to da treba vyrenderovat tak, aby to nebylo poznat 
tak IMHO neni uplne spravne to mit v datech). I vlastni LPIS je zivy system a 
zakresy (geometrie) v nem se postupne meni (sam jsem v nem take upravoval nase 
male louky).


Hlavne bych se zde nerad nekoho dotknul (sam mam nejspis na necem v OSM take 
maslo na hlave), akorat mi jde o to jestli lze rici a nejlepe nekam viditelne 
(treba na wiki) napsat, jak postupovat pripadne jake ficury pouzivat, aby se 
pokud mozno v mape neobjeovaly dalsi relikty luk/poli kolem vetsich luk/poli. 
Pripadne dodat jak to opravit tam, kde to uz je – ja osobne bych relikt 
louky/pole sloucil se sousednim objektem (napr. krovi nebo les) pokud byla 
louka/pole puvodne moc roszahla; pokud neni sousedni objekt pak bych relikt 
smazal a stejne tak v pripade ze je ve skutecnosti mezi loukou/polem a 
sousednim objektem (napr lesem) nejaka mezera – treba prikop, pripadne bych 
relikt zmenil na krovi/grassland apod., nebo bych relikt louky/pole sloucil k 
“velke”louce/”velkemu”poli pokud by byl puvodni zakres spravnejsi oproti LPIS 
(coz bude asi mene casto).



[1] http://osm.kraluvdvur.cz/2011-08-13-osm-kraluv-dvur.pdf
[2] http://osm.kraluvdvur.cz/osm-tracer-lpis-relikty.png
[3] https://www.openstreetmap.org/#map=17/49.96520/13.98907
https://www.openstreetmap.org/#map=17/49.97227/13.97435
https://www.openstreetmap.org/#map=18/49.95781/13.96725


Pokud uz se toto nekde popsalo a vyresilo tak fakt sorry pokud jsem to nenasel

Pavel Bokr

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

Re: [Talk-GB] [Imports] OSM with Wikidata: 27232 matches found in England

[Neil Matthews]

I had a look at your Bristol matches -- most are reasonable, a few issues:

Q5015771 — Cabot Circus — Cabot Circus (way, distance: 165 m) building=yes
Matched to parking not the shopping area -- OSM updated, was a 
suburb place


University of Bristol
one of three matches is to operator UWE Bristol -- OSM updated 
should be UWE


Stoke Park
should probably match to Stoke Park Estate -- remove duplicating 
node from OSM


Brislington West (ward)
matched to Saint Annes -- probably needs checking further?

Cheers,
Neil

P.S. Might be fun to see the items for Bristol that couldn't be matched :-)

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

Re: [OSM-talk-fr] Problème de langue

[Philippe Verdy]

Le 25 janvier 2016 à 22:41, Jérôme Seigneuret  a
écrit :

> Bonjour,
>
> J'appui Jean-Yvon pour le name
>
> Coté relation David à raison sur le fait de gérer des relations avec des
> niveaux multiples ce qui permet d'importer des portions ou de gérer des
> itinéraires logiques par étapes avec les différents niveau (local,
> régional, national...) d'où l'utilisation du name anglais sur une
> super-relation (en Europe quand ça traverse les frontières)
>
> Pour le check d'OSM c'est pas trivial sur le test du nom.
>
> Je reprends le cas de Philippe
> *Noms dans la langue locale et dans la langue par défaut différents*
> *way 83115947 * rawedit
>  josm
>  edit
> 
> *highway* = living_street
> *maxspeed* = 20
> *name* = Chemin des Bauches
> *name:fr* = Lotissement le Manoir
>
> Là on n'est vraiment pas sur une question de langue mais sur une
> incohérence de nom. C'est pas la traduction qui est testé mais juste une
> correspondance entre le territoire le name:[langue] et le name
>

Je n'ai pas dit le contraire, seulement ton débat concernant le territoire
est hors sujet mais c'est pourtant le même test qui est fait : trouver une
correspondance entre un name:lang=* et le name=* Et Là Osmose ne teste pas
tous les name:lang=* mais se limite à chercher le name sur un seul noeud
pour lequel il détermine quelle devrait être "la" langue locale et signale
ensuite l'erreur sur la relation entière puisque alors le name=* par défaut
n'a pas la valeur du name:fr... Même si le noeud n'a qu'une langue locale,
ce n'est celle de la relation entière, hors le résultat s'affiche pour la
relation entière ou le chemin ou polygone entier. C'est ça qui est
défectueux: déterminer la langue locale d'une relation sur un seul de ses
noeuds (choisi en fait arbitrairement) ne peut pas marcher du tout et
donnera des résultats faux si l'objet n'est pas tout entier dans un
territoire linguistique unique (dans ce seul cas le noeud choisi
arbitrairement marchera puisqu'il fait partie de l'objet entièrement
contenu dans la même zone linguistique).

Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait
lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi
sauf que la rue entière est dans le même territoire que le noeud choisi sur
ce chemin. Mais ça marche seulement à moitié.

Je maintiens donc ce que je disais :

- pas besoin de déterminer une langue locale (s'il y en a une malgré tout,
il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette
langue, mais nul besoin que ce soit la langue par défaut pour la valeur du
name=* qui peut rester différente (exemple courant : les noms par défaut en
Chine ou dans les pays arabes peuvent rester en anglais, même si la langue
locale est le chinois ou l'arabe, mais il faudrait autant que possible
libeller précisément ce nom anglais aussi avec name:en=*)

-  dans les pays ou régions officiellement multilingues on ne peut pas
déterminer quelle est la langue par défaut et ce n'est même pas souhaitable
(pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais
serait en fait une approximation grossière et que le nom romanisé serait en
fait issu d'une transliteration latine officielle telle que le romaji
japonais, ou les transliterations officielles ou universitaires du chinois
ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU
et dans les échanges cartographiques internationaux, ou les
transliterations des organisemes internationaux pour l'aviation ou la
navigation maritime) ; en revanche on n'oublira pas de mentionner les noms
dans les langues officielles mais il reste alors le choix du nom "par
défaut" qui devrait être comme c'est vu localement multilingue. Pour que ce
nom par défaut corresponde à un des "name:lang=*" il suffit de l'indiquer
aussi dans "name:mul=*", et le problème est résolu. Pas de problème ensuite
pour n'afficher que l'anglais avec un "name:en=*" si nécessaire (notamment
si le nom multilingue officiel utilise des écritures différentes telles que
latin+arabe ou latin+sinogrammes).

- quand le nom par défaut est une romanisation adaptée à l'usage
international (BPCN, aviation civile, etc.), là on a un "int_name=*" qui
n'est pas non plus forcément le nom anglais ! C'est une (pseudo-)langue à
part (qui n'est ni "name:mul=*", ni "name:en=*"), à usage technique
spécialisé (équivalent à un "name:int=*") pour un certain nombre de normes
de toponymie (ces normes utilisent plus de diacritiques que l'anglais,
exemple avec les noms japonais en internationalisés en romaji, avec les
macrons sur les voyelles longues, autres exemples avec la romanisation du
russe, autre exemple avec la romanisation du serbe dont il existe une
transcription latine officielle avec des haceks et carons, alors que
l'anglais les 

Re: [OSM-talk-fr] wiki : page sur les frontières

[Philippe Verdy]

C'était déjà décrit dans la page sur les boundary et d'autres pages liées
(y compris pour les EPCI)

Le 26 janvier 2016 à 01:25, Jérôme Amagat  a écrit
:

> J'ai écrit une page qui liste les frontières françaises et les tags qui
> vont avec :
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives
>
> il manque plein de choses encore mais je pense que ça pourrait être pas
> mal d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui
> je crois n'apparait nul part sur le wiki. la page n'est pas la ou elle
> serai le mieux.
>
> la page :
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
> devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
> compte c'est la creation de commune nouvelle et la modification des
> communauté de communes et autres EPCI.
>
> ___
> 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] Agiv import

[Glenn Plas]

On 25-01-16 19:38, Marc Gemis wrote:
> On Mon, Jan 25, 2016 at 6:50 PM, Glenn Plas  wrote:
>>> * splitting a building because the garage is clearly separated on AGIV 
>>> imagery
>>
>> You should not have to do that imho, I've never encountered this 'too
>> much building in between' situation.  When the garage is separated
>> visibly on sat images but not in GRB, that's a precarious case, it could
>> be that the building has been replaced but GRB isn't up to date, it
>> could also be that the sat pics used are out of date and there has been
>> an additional construction already in GRB.  You can't tell now what is
>> correct from combining al sources of information.
> 
> It's in Kaprijke, oid 1964089 IMHO this is just sloppy work in GRB.
> For those without access to GRB

Absolutely right, it should be more like the neighbour’s house+garage.
That is some really shitty data you have in that area there.  Someone
really didn't bother being accurate.  They aren't even decent squares.

These cases I've only seen a few of those.  I specifically remember a
building crossing itself, like a closed '8' instead of an '0' or open 8
like here (bit of imagination applies)

I would remove that corner from the main building,  draw the garage
yourself, tag it appropriately. The garage should in fact have it's own
OIDN number in GRB data.

Also, make sure when you create your better OSM bulding, tag it
source:geometry=AGIV (I think to recognise agiv sats).

Then whenever this gets into GRB and trickles down in OSM, you will get
a merge pop-up here (because we use source:geometry=GRB for our building
imports by default), instead of a silent merge...  you'll get notified
there is a conflict, forcing you (=editor) to make a judgement call.

Looks like pretty recent buildings.  Sloppy fieldwork indeed.

It sure varies a lot the quality, probably by the decentralised approach
to this.


Nice catch.

Glenn

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

Re: [OSM-talk-fr] wiki : page sur les frontières

[Jérôme Amagat]

tous les tags sont décrit ailleurs (sauf peut être admin_type) c'est vrai,
cette page resume ce qui est fait pour la france.
Et la page sur les epci c'est celle la :
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlocal_authority
c'est con ca parle que de la france et c'est qu'en anglais.

Le 26 janvier 2016 à 01:45, Philippe Verdy  a écrit :

> C'était déjà décrit dans la page sur les boundary et d'autres pages liées
> (y compris pour les EPCI)
>
> Le 26 janvier 2016 à 01:25, Jérôme Amagat  a
> écrit :
>
>> J'ai écrit une page qui liste les frontières françaises et les tags qui
>> vont avec :
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives
>>
>> il manque plein de choses encore mais je pense que ça pourrait être pas
>> mal d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui
>> je crois n'apparait nul part sur le wiki. la page n'est pas la ou elle
>> serai le mieux.
>>
>> la page :
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
>> devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
>> compte c'est la creation de commune nouvelle et la modification des
>> communauté de communes et autres EPCI.
>>
>> ___
>> 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-be] Bicycle highways

[Glenn Plas]

> However, before talking about relation, I think a specific value should
> be introduced for the _highway key_ : “cyclehighway" for instance. This
> would help the renderer to show those infrastructures differently than
> the usual “cycleway” (the infamous "piste cyclable” that usually sounds
> like an insult for most serious bikers).

We don't map for the renderer (or A renderer for that matter). It's a
bad idea to start molding tags in order to get a pleasant look in the
standard map stylesheet, it's prone to change.  And you disregard all
other (specialiased/thema) maps.

A relation is the best idea.  A renderer doesn't need a special kind of
highway=cyclehighway tag in order to distinguish between the goals of 2
cycleways.

But I still believe that this cyclehighway thing is just a simple
collection of cycleway/lanes etc..., a long one and unless it's
specifically marked like Sander stated, it doesn't really deserve
special treatment.

I know for a fact that in Duffel the cycleway that goes to Antwerp goes
over into a plain road at the train station and back again on the
'highway' a few kilometers north.

But it's still a regular cycleway for those who use it to go to school
in Duffel, it's not a cyclehighway.  I know that area well and it's not
even a cycleway, it's a lane there.  So your proposed solution causes
all sort of troubles as highway can only contain 1 value.

Hence this is where a relation is a lot better and more workable and the
correct approach.  It's exactly why a relation exists in OSM, to
indicate things that belong together in some fashion even though they
aren't the same at all, or even next to each other.

Glenn


> 
> This is however something that has to be discussed on a higher level
> than Belgium. Where is this place ?

Right here I believe :)

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

[OSM-talk-fr] wiki : page sur les frontières

[Jérôme Amagat]

J'ai écrit une page qui liste les frontières françaises et les tags qui
vont avec :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_limites_administratives

il manque plein de choses encore mais je pense que ça pourrait être pas mal
d'avoir quelque chose de ce type. comme le nouveau tag admin_type qui je
crois n'apparait nul part sur le wiki. la page n'est pas la ou elle serai
le mieux.

la page :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives
devrait évolué aussi et mettre en valeur le fait qu'aujourd'hui ce qui
compte c'est la creation de commune nouvelle et la modification des
communauté de communes et autres EPCI.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-co] Importación de datos La Guajira: reservorios y jagüeyes

[hyan...@gmail.com]

Buenas noches comunidad,

Hemos recibido la donación de datos sobre "Reservorios y Jagüeyes" a lo
largo y ancho del departamento de La Guajira.

En la coordinación de la #MapatónXLaGuajira estamos analizando los datos
con el objeto de iniciar el proceso de importación, al respecto unos
primeros comentarios para compartir con ustedes:

   1. Es una capa de 3646 nodos, cada uno con nombres como "jagüey 168",
   "reservorio 1312", etc. Es preferible omitirlos durante la importación,
   agregando solo los de la toponimia;
   2. convertir (manualmente) los nodos en áreas usando imágenes aéreas
   disponibles;
   3. usar la capa original de nodos como referencia para saber dónde están;
   4. se proponen las siguientes etiquetas: a) para los reservorios
   'natural=water' + 'water=reservoir'; b) para los jagüeyes, 'natural=water'
   + 'water=pond'.

La colaboración está abierta, también se abrirá una wiki para ir
documentadolo.

Saludos,

Humberto Yances
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-it] Cimiteri comunali

[Aury88]

CUS Privati Enti Imprese wrote
> Salve amici,
> possibile che non sia stato mai chiesto?:
> Ma voi li usate i tag religion-related sui cimiteri?
> Intendo i *cimiteri comunali*.
> Se è comunale ci vanno atei, testimoni di geova, mussulmani, borbonici e 
> ipovedenti allo stesso modo. (una tumulazione non si rifiuta a nessuno)
> 
> Mi sbaglio?
> 
> Daniele

io se è chiara la consacrazione metto il tag religious altrimenti,
probabilmente sbagliando, non metto nulla.
nei grave_yard è nel 99,99% dei casi uguale a quello della chiesetta
limitrofa, per tutti gli altri tipi di cimitero non è una cosa
certa...spesso i cimiteri comunali, con forte presenza di una comunità
religiosa diversa dal resto della popolazione, c'è un area dedicata ad una
specifica confessione...ma anche così l classificazione religious non è
chiarissima...in italia come un po' tutti i luoghi/opere pubbliche i
cimiteri, anche non propriamente cristiani, hanno subito una consacrazione
cristiana...ma lo stesso identico trattamento lo ricevono ponti, scuole,
uffici comunali, parchetti, stazione dei treni...quindi direi che quello non
può essere il criterio...
 io direi che se c'è una cappella all'interno con rappresentata una sola
religione ci si possa arrischiare ad estendere il relativo tag religious a
tutto il cimitero. altrimenti nulla o la religione più diffusa tra i defunti
seppelliti nel luogo ;-P



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Cimiteri-comunali-tp5865457p5865672.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Cimiteri comunali

[Martin Koppenhoefer]

2016-01-25 8:48 GMT+01:00 Aury88 :

> ora non metto in dubbio che sia una traduzione non corretta o un utilizzo
> non appropriato alla reale interpretazione del termine graveyard
>


veramente, il problema sta in wikipedia se dice che sono la stessa cosa un
graveyard ed un cemetery. Guardate per esempio qui:
http://www.thehindu.com/books/know-your-english/know-your-english-difference-between-graveyard-and-cemetery/article2568640.ece

Anche se comunemente e ignorando la storia i due termini sono spesso usati
per dire la stessa cosa, in realtà quella sottile (?) differenza ci sta.
Anche in Italia si trovano sia casi di graveyard (all'interno del paese,
dietro/a canto una chiesa) che di cemetery (tipicamente al lato o fuori
paese, senza chiesa / talvolta con capella funeraria).


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

Re: [Talk-it] Cimiteri comunali

[Martin Koppenhoefer]

2016-01-25 8:57 GMT+01:00 Aury88 :

> io se è chiara la consacrazione metto il tag religious altrimenti,
> probabilmente sbagliando, non metto nulla.
>



per me la consacrazione non ci si vuole (per forza, ma non metto in dubbio
che per i cimiteri ci sia probabilmente), per esempio ad un asilo nido
della chiesa ci aggiungo tranquillamente un religion=christian.

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

Re: [Talk-it] Materiale per "OSM per ciclisti"

[Luca Delucchi]

Ciao Volker,

2016-01-23 20:01 GMT+01:00 Volker Schmidt :
> Mi sono impegnato di organizzare dei mini-corsi all'interno della FIAB
> (Federazione Italiana Amici della Bicicletta) su come inserire dati
> rilevanti per ciclisti in OSM. L'accento dovrebbe essere su:
>
> aspetti delle strade rilevanti per ciclisti
> ciclopiste
> ciclovie (relazioni)
> controllo di qualità (in particolare delle relazioni per le ciclovie)
>
> Devo preparare una dispensa e per questo cerco materiale ed idee.

magari potrebbe essere utile creare il materiale in modo collaborativo?
possiamo usare il canale osmitalia di github e come piattaforma per
esempio sphinx (permette di avere diversi formati di output tra cui
PDF, HTML, slides)

> Se qualcuno mi vuole dare una mano anche per gli eventi stessi, sarei più
> che contento.
> Penso a due o tre eventi di un giorno, uno al nord, uno nel centro e uno nel
> sud.
>

per quello al nord sono ben disposto ad aiutare

> Volker
> (Padova)
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [OSM-talk-be] Agiv import

[Glenn Plas]

> I also mean when the geometry in OSM is actually better than in
> the GRB. I'm thinking in particular about VIVES in Bruges. The GRB
>  building shape is just wrong. In OSM it's better (may be not 
> perfect, it's a complex building) and 3D mapped. 
> http://www.openstreetmap.org/#map=18/51.18741/3.20325

Yes of course. that's why I call it a merge. since this process
encompasses using AGIV sat layer, and GRB layer in JOSM itself, it's
not hard to see where GRB has got it wrong.

No need to worry about losing good OSM data, when done right..

Glenn

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

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Moises Arcos]

Buenos días,

una idea que se me ocurre es que desde OSM España se lance una campaña de
etiquetado de calles, al igual que se hacen con las fuentes de agua potable.
Creo que sería una oportunidad para implicar a mucha más gente en a
definición de las calles.

En Andalucía tenemos disponible el Callejero Digital de Andalucía Unificado
[1] que nos puede ayudar en la labor, ya que su licencia es abierta, aunque
lo mejor es ir a la calle y recoger el nombre directamente in situ.
Al igual que hay para el catastro ¿Existe alguna página en la wiki que
podamos tener de referencia en donde esté el total de calles de un
municipio frente a las que están mapeadas? De esta forma podríamos ver la
completitud del municipio en cuanto a los criterios que planteas y sería
mucho más cómodo distribuir a equipos de trabajo en cada una de las zonas,
para que revisen el nombre de sus calles.

Un saludo!!!

[1] http://www.callejerodeandalucia.es/

El 23 de enero de 2016, 21:19, yo paseopor  escribió:

> ¡Buenas gente!
>
> Aunque mi ámbito habitual suele ser más la lista catalana, a veces me doy
> un garbeo por el grupo español de Telegram y comentando el desarrollo de un
> nuevo preset para una campaña de etiquetaje "básico" llegamos a la
> conclusión de que en ciertas zonas de España queda mucho por hacer. Así que
> me dispuse a comprobarlo un poco por encima, sin mucho esfuerzo. Usé
> http://qa.poole.ch/ Y estos son los resultados que cualquiera puede
> comprobar.
>
> De capitales de provincia las que requieren intervención urgente o similar:
> -Ourense
> -Cuenca
> *Madrid (la capital de España no puede tener calles sin nombrar, lo
> siento, es cuestión de imagen...lo mismo diría de Barcelona)
> -Toledo
> -Badajoz
> -Murcia
> -Jerez
>
> y los barrios exteriores y zonas nuevas de:
>
> -Tarragona
> -Almería
> -Sevilla
> -Cádiz
>
> Mención especial a Salamanca...vereis como la herramienta no le encuentra
> NINGÚN ERROR de NOName, un aplauso a los salmantinos y a quien edita en la
> zona ;)
>
> Como intervención en el grupo catalán de Telegram hemos debatido unos
> niveles que toda población debería tener, a fin de homogeneizar y mejorar
> el desarrollo del mapa:
>
> -Nivel 1: Trazado y nombre de calle
> -Nivel 2: Sentido de circulación, plazas,parques, lugares públicos y
> privados.
> -Nivel 3: Urbanizaciones, granjas,masías, usos del suelo (es lo que da
> color al mapa, residencial,comercial,industrial),delimitar correctamente
> límites administrativos.
>
> Para todo ello se piensa en el desarrollo de una predefinición de menú
> para JOSM que muestre las opciones dirigidas a esos niveles
> "básicos".También se comenta el envío de mensajes vía redes sociales a los
> ayuntamientos y comunidades de la zona para animar al uso y edición de OSM.
>
> -En el grupo español de Telegram se comentaba que tan importante son los
> sentidos de circulación como también los propios portales de la calle,
> aunque eso ya requiere de un etiquetaje un poco más elaborado.También se
> hablaba de exponerlo en la wiki, así como diversas revisiones del
> transporte público, etc.
>
> Todo son ideas, todo es mejorable, no se trata de poner el dedo en la
> llaga o señalar a uno u otro, simplemente se trata de constatar un hecho y
> qué puede hacer la comunidad para mejorarlo.
>
> ¿Qué pensais vosotros?
> Salut i comunitats
> yopaseopor
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-talk-fr] Problème de langue

[Dominique Faure]

Bonjour,

"Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
je sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
lui redonner son nom et y rattacher quelques bâtiments dans une relation
associatedStreet.

Depuis cette modification, j'ai ce message d'erreur dans osmose (
http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -

​A noter que ma modification à eu lieu ici:
http://www.openstreetmap.org/way/391928538


Merci d'avance pour vos éclaircissements.
-- 
Dominique
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de langue

[Florent RICHARD]

Bonjour,

Pour un objet situé en France, le nom par défaut (tag “name”) doit correspondre 
au nom en langue française (tag “name:fr”). 
Dans ton cas, l’objet est nommé par défaut en allemand.

Florent

From: Dominique Faure 
Sent: Monday, January 25, 2016 10:40 AM
To: talk-fr@openstreetmap.org 
Subject: [OSM-talk-fr] Problème de langue

Bonjour,


"Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me 
débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que je 
sèche un peu...

J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour lui 
redonner son nom et y rattacher quelques bâtiments dans une relation 
associatedStreet.


Depuis cette modification, j'ai ce message d'erreur dans osmose 
(http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):

=8<- - - - -
Noms dans la langue locale et dans la langue par défaut différents

e-road:class = A-intermediate
name = Europastraße 54
name:de = Europastraße 54
name:fr = Route européenne 54
network = e-road
ref = E 54
route = road
type = route
wikidata = Q664865
wikipedia = fr:Route européenne 54
=8<- - - - -


​A noter que ma modification à eu lieu ici: 
http://www.openstreetmap.org/way/391928538



Merci d'avance pour vos éclaircissements.
-- 

Dominique



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

Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

[Ross]

On 25/01/16 14:31, Ian Sergeant wrote:

On 25 January 2016 at 14:48, Ross  wrote


How do you know it is the physical feature?
Just because it follows approximately the feature does not mean it is.  When 
originally gazetted the physical feature may have been located differently 
(roads, railways realigned, rivers making new paths)  Don't automatically 
assume that the feature is still in the same place without looking at the 
imagery or physical survey.  Don't assume that the boundary changes to the new 
position of the road, etc.

There are numerous ways you can 'know' something.  Legislation
(including regulations, court judgement) is often the primary thing
involved here.  I'm not calling on people to guess, but we should bear
in mind that OSM is an evolution, and we have often used these
features in evolving the map until we locate or have free access to a
definitive source.

So you check each and every time for a source that shows the boundary 
you are working on is the physical feature and then provide the source 
in a tag?


As you suggest most people will just guess and a lot of the time it may 
be so but it still causes issues with later changes and corrupting the 
original data (such as the NSW reserves boundaries).


And the guess does not get fixed there are many locations where roads 
are still on admin boundaries but the boundary is no long there (changes 
to boundaries) or the road has moved but  nobody comes back to correct it.



But the border has not changed the river might have but there is no change to 
the border from when it was first surveyed/gazetted.  The border is the line as 
when gazetted, not as where the riverbank is now.

I think you're wrong.  The border has been defined by High Court
Judgement as including accretions and erosion.  Including landslip
such as in the Ward case.

Of course, where the river has fundamentally changed course, the
original course remains the boundary.  But gradual erosion actually
changes the border.

Ian.


But not in all cases as your previous post suggested and the location I 
pointed out shows.


Cheers
Ross


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

Re: [Talk-cz] Oprava vadne fotky rozcestniku?

[Petr Vozdecký]

ne 3 m ale 3 km!



-- Původní zpráva --

Od: Michal Grézl 

Datum: 24. 1. 2016 v 23:48:55

Předmět: Re: [Talk-cz] Oprava vadne fotky rozcestniku?



ja to presunu, kdyz reknes presne kam. presouvaci funkce bude az na novym 
osm.cz fakt 3 metry? to nema cenu ani resit, to je uplne v ramci chyby gps 
2016-01-20 17:18 GMT+01:00 Petr Vozdecký : > Ahoj, > > nahodne jsem 
zaregistroval vadne umistenou fotku rozcestniku > > jde o http://api.
openstreetmap.cz/table/id/4517 > > zrovna jsem jej sam pred par dny fotil, 
ale jednak je ho v systemu jen pulka > (druha je na druhe strane stromu) a 
soucasne plati, ze ma souradnice > umistene o 3.217 m vzdusnou carou 
jinde... > > Jak postupovat? Zatim jsem udelal to, ze jserm na vyse uvedenem
URL editoval > pole poznamka a tam jsem to strucne uvedl... > > vop > > 
___ > Talk-cz mailing list > Talk-
c...@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > --
Michal Grézl http://openstreetmap.cz ___
 Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.
openstreetmap.org/listinfo/talk-cz___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Jorge López]

Hola,

Yo creo que lo primero de todo tendríamos que ponernos de acuerdo y 
actualizar la wiki, que está bastante desactualizada. Una vez que eso 
esté ya podremos ver que zonas necesitan más atención.


Un saludo

Jorge

El 25/01/2016 a las 10:31, Moises Arcos escribió:

Buenos días,

una idea que se me ocurre es que desde OSM España se lance una campaña 
de etiquetado de calles, al igual que se hacen con las fuentes de agua 
potable.
Creo que sería una oportunidad para implicar a mucha más gente en a 
definición de las calles.


En Andalucía tenemos disponible el Callejero Digital de Andalucía 
Unificado [1] que nos puede ayudar en la labor, ya que su licencia es 
abierta, aunque lo mejor es ir a la calle y recoger el nombre 
directamente in situ.
Al igual que hay para el catastro ¿Existe alguna página en la wiki que 
podamos tener de referencia en donde esté el total de calles de un 
municipio frente a las que están mapeadas? De esta forma podríamos ver 
la completitud del municipio en cuanto a los criterios que planteas y 
sería mucho más cómodo distribuir a equipos de trabajo en cada una de 
las zonas, para que revisen el nombre de sus calles.


Un saludo!!!

[1] http://www.callejerodeandalucia.es/

El 23 de enero de 2016, 21:19, yo paseopor > escribió:


¡Buenas gente!

Aunque mi ámbito habitual suele ser más la lista catalana, a veces
me doy un garbeo por el grupo español de Telegram y comentando el
desarrollo de un nuevo preset para una campaña de etiquetaje
"básico" llegamos a la conclusión de que en ciertas zonas de
España queda mucho por hacer. Así que me dispuse a comprobarlo un
poco por encima, sin mucho esfuerzo. Usé http://qa.poole.ch/ Y
estos son los resultados que cualquiera puede comprobar.

De capitales de provincia las que requieren intervención urgente o
similar:
-Ourense
-Cuenca
*Madrid (la capital de España no puede tener calles sin nombrar,
lo siento, es cuestión de imagen...lo mismo diría de Barcelona)
-Toledo
-Badajoz
-Murcia
-Jerez

y los barrios exteriores y zonas nuevas de:

-Tarragona
-Almería
-Sevilla
-Cádiz

Mención especial a Salamanca...vereis como la herramienta no le
encuentra NINGÚN ERROR de NOName, un aplauso a los salmantinos y a
quien edita en la zona ;)

Como intervención en el grupo catalán de Telegram hemos debatido
unos niveles que toda población debería tener, a fin de
homogeneizar y mejorar el desarrollo del mapa:

-Nivel 1: Trazado y nombre de calle
-Nivel 2: Sentido de circulación, plazas,parques, lugares públicos
y privados.
-Nivel 3: Urbanizaciones, granjas,masías, usos del suelo (es lo
que da color al mapa, residencial,comercial,industrial),delimitar
correctamente límites administrativos.

Para todo ello se piensa en el desarrollo de una predefinición de
menú para JOSM que muestre las opciones dirigidas a esos niveles
"básicos".También se comenta el envío de mensajes vía redes
sociales a los ayuntamientos y comunidades de la zona para animar
al uso y edición de OSM.

-En el grupo español de Telegram se comentaba que tan importante
son los sentidos de circulación como también los propios portales
de la calle, aunque eso ya requiere de un etiquetaje un poco más
elaborado.También se hablaba de exponerlo en la wiki, así como
diversas revisiones del transporte público, etc.

Todo son ideas, todo es mejorable, no se trata de poner el dedo en
la llaga o señalar a uno u otro, simplemente se trata de constatar
un hecho y qué puede hacer la comunidad para mejorarlo.

¿Qué pensais vosotros?
Salut i comunitats
yopaseopor

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




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




---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Moises Arcos]

¿En qué página de la wiki se está reflejando este tema? Para echarle un ojo

El 25 de enero de 2016, 10:40, Jorge López 
escribió:

> Hola,
>
> Yo creo que lo primero de todo tendríamos que ponernos de acuerdo y
> actualizar la wiki, que está bastante desactualizada. Una vez que eso esté
> ya podremos ver que zonas necesitan más atención.
>
> Un saludo
>
> Jorge
>
>
> El 25/01/2016 a las 10:31, Moises Arcos escribió:
>
> Buenos días,
>
> una idea que se me ocurre es que desde OSM España se lance una campaña de
> etiquetado de calles, al igual que se hacen con las fuentes de agua potable.
> Creo que sería una oportunidad para implicar a mucha más gente en a
> definición de las calles.
>
> En Andalucía tenemos disponible el Callejero Digital de Andalucía
> Unificado [1] que nos puede ayudar en la labor, ya que su licencia es
> abierta, aunque lo mejor es ir a la calle y recoger el nombre directamente
> in situ.
> Al igual que hay para el catastro ¿Existe alguna página en la wiki que
> podamos tener de referencia en donde esté el total de calles de un
> municipio frente a las que están mapeadas? De esta forma podríamos ver la
> completitud del municipio en cuanto a los criterios que planteas y sería
> mucho más cómodo distribuir a equipos de trabajo en cada una de las zonas,
> para que revisen el nombre de sus calles.
>
> Un saludo!!!
>
> [1] http://www.callejerodeandalucia.es/
>
> El 23 de enero de 2016, 21:19, yo paseopor 
> escribió:
>
>> ¡Buenas gente!
>>
>> Aunque mi ámbito habitual suele ser más la lista catalana, a veces me doy
>> un garbeo por el grupo español de Telegram y comentando el desarrollo de un
>> nuevo preset para una campaña de etiquetaje "básico" llegamos a la
>> conclusión de que en ciertas zonas de España queda mucho por hacer. Así que
>> me dispuse a comprobarlo un poco por encima, sin mucho esfuerzo. Usé
>> http://qa.poole.ch/ Y estos son los resultados que cualquiera puede
>> comprobar.
>>
>> De capitales de provincia las que requieren intervención urgente o
>> similar:
>> -Ourense
>> -Cuenca
>> *Madrid (la capital de España no puede tener calles sin nombrar, lo
>> siento, es cuestión de imagen...lo mismo diría de Barcelona)
>> -Toledo
>> -Badajoz
>> -Murcia
>> -Jerez
>>
>> y los barrios exteriores y zonas nuevas de:
>>
>> -Tarragona
>> -Almería
>> -Sevilla
>> -Cádiz
>>
>> Mención especial a Salamanca...vereis como la herramienta no le encuentra
>> NINGÚN ERROR de NOName, un aplauso a los salmantinos y a quien edita en la
>> zona ;)
>>
>> Como intervención en el grupo catalán de Telegram hemos debatido unos
>> niveles que toda población debería tener, a fin de homogeneizar y mejorar
>> el desarrollo del mapa:
>>
>> -Nivel 1: Trazado y nombre de calle
>> -Nivel 2: Sentido de circulación, plazas,parques, lugares públicos y
>> privados.
>> -Nivel 3: Urbanizaciones, granjas,masías, usos del suelo (es lo que da
>> color al mapa, residencial,comercial,industrial),delimitar correctamente
>> límites administrativos.
>>
>> Para todo ello se piensa en el desarrollo de una predefinición de menú
>> para JOSM que muestre las opciones dirigidas a esos niveles
>> "básicos".También se comenta el envío de mensajes vía redes sociales a los
>> ayuntamientos y comunidades de la zona para animar al uso y edición de OSM.
>>
>> -En el grupo español de Telegram se comentaba que tan importante son los
>> sentidos de circulación como también los propios portales de la calle,
>> aunque eso ya requiere de un etiquetaje un poco más elaborado.También se
>> hablaba de exponerlo en la wiki, así como diversas revisiones del
>> transporte público, etc.
>>
>> Todo son ideas, todo es mejorable, no se trata de poner el dedo en la
>> llaga o señalar a uno u otro, simplemente se trata de constatar un hecho y
>> qué puede hacer la comunidad para mejorarlo.
>>
>> ¿Qué pensais vosotros?
>> Salut i comunitats
>> yopaseopor
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
>
> ___
> Talk-es mailing 
> listTalk-es@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-es
>
>
>
> 
>  Este
> correo electrónico se ha enviado desde un equipo libre de virus y protegido
> por Avast.
> www.avast.com
> 
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Problème de langue

[Jérôme Seigneuret]

Bonjour,

J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
de modification. A moins de mettre le tag name en Anglais...

Car cette alerte est à mon avis seulement valable pour les objets (node,
way, relation) se limitant à un territoire dont la langue est identifié
dans notre cas fr et non à des superpostion entre territoires

Dans ton cas, la relation dépasse les frontières. Donc que choisir dans ce
cas... Le name en Anglais, le name du pays de départ (qui soit disant
passant est différent suivant le sens).

J'aurais choisi un nom FR pour les tronçons en France un nom Allemand pour
les tronçons Allemand et pour la relation (Euro), le nom en anglais et
name:fr=* name:de=*

le name:fr permet de toute manière de trouver cette relation dans Nominatim

Jérôme

Le 25 janvier 2016 à 10:40, Dominique Faure  a
écrit :

> Bonjour,
>
> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
> je sèche un peu...
>
> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
> lui redonner son nom et y rattacher quelques bâtiments dans une relation
> associatedStreet.
>
> Depuis cette modification, j'ai ce message d'erreur dans osmose (
> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>
> =8<- - - - -
> Noms dans la langue locale et dans la langue par défaut différents
>
> e-road:class = A-intermediate
> name = Europastraße 54
> name:de = Europastraße 54
> name:fr = Route européenne 54
> network = e-road
> ref = E 54
> route = road
> type = route
> wikidata = Q664865
> wikipedia = fr:Route européenne 54
> =8<- - - - -
>
> ​A noter que ma modification à eu lieu ici:
> http://www.openstreetmap.org/way/391928538
>
>
> Merci d'avance pour vos éclaircissements.
> --
> Dominique
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

[Ian Sergeant]

On 25 January 2016 at 19:38, Ross  wrote:

> And the guess does not get fixed there are many locations where roads are
> still on admin boundaries but the boundary is no long there (changes to
> boundaries) or the road has moved but  nobody comes back to correct it.


To me this seems like a more general problem.  Mapping bare areas gets
done, but when a road moves or a boundary moves then they don't tend
to get noticed as much.  After the ABS2006 data was imported, it
wasn't linked to features, but quickly fell out of date as suburbs
changed and were added.

Ian.

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

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Moises Arcos]

El 25 de enero de 2016, 11:28, Jorge Sanz Sanfructuoso 
escribió:

> Hola.
> Creo que por ahora en ninguna página de la wiki pero la idea es ponerlo.
> Después de escribir el primer correo en Telegram de una plantilla que hay
> en la wiki para ver el progreso en diferentes zonas de diferentes cosas que
> se deberían etiquetar, para ir marcándolo. Lo están usando por ejemplo en
> el Corredor del Henares.
> http://wiki.openstreetmap.org/wiki/Corredor_del_Henares
> Lo primero y más importante es tener todas las capitales con nombres de
> calles y las direcciones si es posible. Por lo que creo que se debería
> empezar por una tabla como esta en la wiki con todas las capitales de
> provincia e ir actualizando hasta que estén todas con unos mínimo.
>

Me parece correcto, tener un listado en el que vayamos viendo el estado que
tiene cada ciudad.


>
> En cuanto a saber el total de calles en cada ciudad creo que eso va a
> estar difícil. Yo en mi caso en Salamanca conseguí un listado de calles del
> ayuntamiento hace tiempo que tenía fallos pero más o menos valía. El otro
> día vi otro listado más moderno que a ver si lo compruebo. Pero en esto no
> he visto ningún listado nacional que podamos usar, que va haber que ir a
> los ayuntamientos a pedirlo o buscarlo si se quiere. Pero tampoco pienso
> que haga falta un listado aunque pueda ser útil. Con la herramienta
> http://qa.poole.ch/ se puede ver donde faltan y donde no falta el nombre
> de las calles.
>

Me parece bien, pero eso sólo detecta las calles que ya están creadas en
OSM y que no tienen nombre pero no las calles que aún no están añadidas,
por lo que creo que tenemos dos problemas diferentes:
1.- Calles no cartografiadas
2.- Calles cartografiadas pero sin nombre

De ahí que comentase acudir a una fuente oficial que nos ayudase en ambas
labores.
Aún así sigo pensando que la mejor forma es salir a la calle tomar trazas
gpx y los nombres de cada una de ellas y subirlas a OSM como reflejo de la
realidad.


>
> Lo de la campaña de etiquetado de calles como se hizo con las fuentes me
> parece buena idea. Con tanta tralla que dimos en telegram ya alguno se
> animó a etiquetar alguna calle que faltaba jajaja.
>

Me parece que un primer paso podría ser definir una página en la wiki con
todas las ciudades de España clasificadas por comunidades autónomas,
acompañadas de un estado.
A partir de esta primera tabla, por ejemplo en ciudades muy grandes se
podrían dividir por barrios o distritos, de forma que podamos ver como se
van completando.

Cuenta conmigo para lo que necesites.


>
> Un saludo.
>
>
> El lun., 25 ene. 2016 a las 10:46, Moises Arcos ()
> escribió:
>
>> ¿En qué página de la wiki se está reflejando este tema? Para echarle un
>> ojo
>>
>> El 25 de enero de 2016, 10:40, Jorge López 
>> escribió:
>>
>>> Hola,
>>>
>>> Yo creo que lo primero de todo tendríamos que ponernos de acuerdo y
>>> actualizar la wiki, que está bastante desactualizada. Una vez que eso esté
>>> ya podremos ver que zonas necesitan más atención.
>>>
>>> Un saludo
>>>
>>> Jorge
>>>
>>>
>>> El 25/01/2016 a las 10:31, Moises Arcos escribió:
>>>
>>> Buenos días,
>>>
>>> una idea que se me ocurre es que desde OSM España se lance una campaña
>>> de etiquetado de calles, al igual que se hacen con las fuentes de agua
>>> potable.
>>> Creo que sería una oportunidad para implicar a mucha más gente en a
>>> definición de las calles.
>>>
>>> En Andalucía tenemos disponible el Callejero Digital de Andalucía
>>> Unificado [1] que nos puede ayudar en la labor, ya que su licencia es
>>> abierta, aunque lo mejor es ir a la calle y recoger el nombre directamente
>>> in situ.
>>> Al igual que hay para el catastro ¿Existe alguna página en la wiki que
>>> podamos tener de referencia en donde esté el total de calles de un
>>> municipio frente a las que están mapeadas? De esta forma podríamos ver la
>>> completitud del municipio en cuanto a los criterios que planteas y sería
>>> mucho más cómodo distribuir a equipos de trabajo en cada una de las zonas,
>>> para que revisen el nombre de sus calles.
>>>
>>> Un saludo!!!
>>>
>>> [1] http://www.callejerodeandalucia.es/
>>>
>>> El 23 de enero de 2016, 21:19, yo paseopor 
>>> escribió:
>>>
 ¡Buenas gente!

 Aunque mi ámbito habitual suele ser más la lista catalana, a veces me
 doy un garbeo por el grupo español de Telegram y comentando el desarrollo
 de un nuevo preset para una campaña de etiquetaje "básico" llegamos a la
 conclusión de que en ciertas zonas de España queda mucho por hacer. Así que
 me dispuse a comprobarlo un poco por encima, sin mucho esfuerzo. Usé
 http://qa.poole.ch/ Y estos son los resultados que cualquiera puede
 comprobar.

 De capitales de provincia las que requieren intervención urgente o
 similar:
 -Ourense
 -Cuenca
 *Madrid (la capital de España no puede tener calles sin nombrar, lo
 

[OSM-talk-fr] Couverture voies et noms de voies

[Bruno]

Bonjour,

Dans le cadre d'un projet en entreprise et pour convaincre de l'utilité 
d'OSM , j'aurais besoin de montrer de façon simple et visuelle la 
couverture actuelle de la base OSM en ce qui concerne la voirie  et le 
noms des voies , pas les adresses ni le bâti.


Un peu comme tiles et les zones à mapper mais juste le rouge et avec par 
exemple un % de noms des voies par département.

http://tile.openstreetmap.fr/

Si il existe déjà quelque chose je suis preneur.

Cordialement,
Bruno.

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

Re: [Talk-it] sentieri segnalati ma senza ref

[Pio]

Io nel marcare i sentieri con relazioni, faccio riferimentoalle indicazoni
di:
IT:Hiking
  :

/"Una relazione va attribuita ad un sentiero solo se questo è segnalato da
apposita segnaletica, se ci sono delle guide che lo descrivono o se è
riconosciuto ufficialmente e percorso regolarmente"/

altrimenti utilizzo highwway=path con gli attributi indicati nella stessa
pagina.

Ciao



--
View this message in context: 
http://gis.19327.n5.nabble.com/sentieri-segnalati-ma-senza-ref-tp5865487p5865700.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Jorge Sanz Sanfructuoso]

El lun., 25 ene. 2016 a las 11:44, Moises Arcos ()
escribió:

> El 25 de enero de 2016, 11:28, Jorge Sanz Sanfructuoso 
> escribió:
>
>> Hola.
>> Creo que por ahora en ninguna página de la wiki pero la idea es ponerlo.
>> Después de escribir el primer correo en Telegram de una plantilla que hay
>> en la wiki para ver el progreso en diferentes zonas de diferentes cosas que
>> se deberían etiquetar, para ir marcándolo. Lo están usando por ejemplo en
>> el Corredor del Henares.
>> http://wiki.openstreetmap.org/wiki/Corredor_del_Henares
>> Lo primero y más importante es tener todas las capitales con nombres de
>> calles y las direcciones si es posible. Por lo que creo que se debería
>> empezar por una tabla como esta en la wiki con todas las capitales de
>> provincia e ir actualizando hasta que estén todas con unos mínimo.
>>
>
Me parece correcto, tener un listado en el que vayamos viendo el estado que
tiene cada ciudad.


>> En cuanto a saber el total de calles en cada ciudad creo que eso va a
>> estar difícil. Yo en mi caso en Salamanca conseguí un listado de calles del
>> ayuntamiento hace tiempo que tenía fallos pero más o menos valía. El otro
>> día vi otro listado más moderno que a ver si lo compruebo. Pero en esto no
>> he visto ningún listado nacional que podamos usar, que va haber que ir a
>> los ayuntamientos a pedirlo o buscarlo si se quiere. Pero tampoco pienso
>> que haga falta un listado aunque pueda ser útil. Con la herramienta
>> http://qa.poole.ch/ se puede ver donde faltan y donde no falta el nombre
>> de las calles.
>>
>
> Me parece bien, pero eso sólo detecta las calles que ya están creadas en
> OSM y que no tienen nombre pero no las calles que aún no están añadidas,
> por lo que creo que tenemos dos problemas diferentes:
> 1.- Calles no cartografiadas
> 2.- Calles cartografiadas pero sin nombre
>

Cierto ese caso no lo había tenido en cuenta. En las ciudades espero que ya
de esos casos tengamos pocos pero seguro que hay. Dependerá mucho de las
ciudades. En la mayoría, si están todos los nombres lo normal es que el que
puso los nombres se preocupara de ver por las ortofotos si faltan calles
por dibujar pero claro no lo podemos asegurar.


> De ahí que comentase acudir a una fuente oficial que nos ayudase en ambas
> labores.
> Aún así sigo pensando que la mejor forma es salir a la calle tomar trazas
> gpx y los nombres de cada una de ellas y subirlas a OSM como reflejo de la
> realidad.
>

En las ciudades que hay gente editando es lo suyo el problema es que hay
ciudades en las que nadie está editando por lo menos asiduamente. Y en esos
casos o tiramos de datos abiertos o organizamos una party y vamos a la
ciudad que sea jajaja.

>
>
>>
>> Lo de la campaña de etiquetado de calles como se hizo con las fuentes me
>> parece buena idea. Con tanta tralla que dimos en telegram ya alguno se
>> animó a etiquetar alguna calle que faltaba jajaja.
>>
>
> Me parece que un primer paso podría ser definir una página en la wiki con
> todas las ciudades de España clasificadas por comunidades autónomas,
> acompañadas de un estado.
> A partir de esta primera tabla, por ejemplo en ciudades muy grandes se
> podrían dividir por barrios o distritos, de forma que podamos ver como se
> van completando.
>
> Cuenta conmigo para lo que necesites.
>

Me parece una buena manera de ponerlo.

Voy a empezar exámenes así que tengo poco tiempo ahora, pero en algún rato
puedo ponerme hacer lo de la wiki.

>
>
>>
>> Un saludo.
>>
>>
>> El lun., 25 ene. 2016 a las 10:46, Moises Arcos ()
>> escribió:
>>
>>> ¿En qué página de la wiki se está reflejando este tema? Para echarle un
>>> ojo
>>>
>>> El 25 de enero de 2016, 10:40, Jorge López 
>>> escribió:
>>>
 Hola,

 Yo creo que lo primero de todo tendríamos que ponernos de acuerdo y
 actualizar la wiki, que está bastante desactualizada. Una vez que eso esté
 ya podremos ver que zonas necesitan más atención.

 Un saludo

 Jorge


 El 25/01/2016 a las 10:31, Moises Arcos escribió:

 Buenos días,

 una idea que se me ocurre es que desde OSM España se lance una campaña
 de etiquetado de calles, al igual que se hacen con las fuentes de agua
 potable.
 Creo que sería una oportunidad para implicar a mucha más gente en a
 definición de las calles.

 En Andalucía tenemos disponible el Callejero Digital de Andalucía
 Unificado [1] que nos puede ayudar en la labor, ya que su licencia es
 abierta, aunque lo mejor es ir a la calle y recoger el nombre directamente
 in situ.
 Al igual que hay para el catastro ¿Existe alguna página en la wiki que
 podamos tener de referencia en donde esté el total de calles de un
 municipio frente a las que están mapeadas? De esta forma podríamos ver la
 completitud del municipio en cuanto a los criterios que planteas y sería
 mucho más cómodo distribuir a equipos 

Re: [Talk-es] Etiquetaje; estado de las calles españolas

[Jorge Sanz Sanfructuoso]

Hola.
Creo que por ahora en ninguna página de la wiki pero la idea es ponerlo.
Después de escribir el primer correo en Telegram de una plantilla que hay
en la wiki para ver el progreso en diferentes zonas de diferentes cosas que
se deberían etiquetar, para ir marcándolo. Lo están usando por ejemplo en
el Corredor del Henares.
http://wiki.openstreetmap.org/wiki/Corredor_del_Henares
Lo primero y más importante es tener todas las capitales con nombres de
calles y las direcciones si es posible. Por lo que creo que se debería
empezar por una tabla como esta en la wiki con todas las capitales de
provincia e ir actualizando hasta que estén todas con unos mínimo.

En cuanto a saber el total de calles en cada ciudad creo que eso va a estar
difícil. Yo en mi caso en Salamanca conseguí un listado de calles del
ayuntamiento hace tiempo que tenía fallos pero más o menos valía. El otro
día vi otro listado más moderno que a ver si lo compruebo. Pero en esto no
he visto ningún listado nacional que podamos usar, que va haber que ir a
los ayuntamientos a pedirlo o buscarlo si se quiere. Pero tampoco pienso
que haga falta un listado aunque pueda ser útil. Con la herramienta
http://qa.poole.ch/ se puede ver donde faltan y donde no falta el nombre de
las calles.

Lo de la campaña de etiquetado de calles como se hizo con las fuentes me
parece buena idea. Con tanta tralla que dimos en telegram ya alguno se
animó a etiquetar alguna calle que faltaba jajaja.

Un saludo.


El lun., 25 ene. 2016 a las 10:46, Moises Arcos ()
escribió:

> ¿En qué página de la wiki se está reflejando este tema? Para echarle un ojo
>
> El 25 de enero de 2016, 10:40, Jorge López 
> escribió:
>
>> Hola,
>>
>> Yo creo que lo primero de todo tendríamos que ponernos de acuerdo y
>> actualizar la wiki, que está bastante desactualizada. Una vez que eso esté
>> ya podremos ver que zonas necesitan más atención.
>>
>> Un saludo
>>
>> Jorge
>>
>>
>> El 25/01/2016 a las 10:31, Moises Arcos escribió:
>>
>> Buenos días,
>>
>> una idea que se me ocurre es que desde OSM España se lance una campaña de
>> etiquetado de calles, al igual que se hacen con las fuentes de agua potable.
>> Creo que sería una oportunidad para implicar a mucha más gente en a
>> definición de las calles.
>>
>> En Andalucía tenemos disponible el Callejero Digital de Andalucía
>> Unificado [1] que nos puede ayudar en la labor, ya que su licencia es
>> abierta, aunque lo mejor es ir a la calle y recoger el nombre directamente
>> in situ.
>> Al igual que hay para el catastro ¿Existe alguna página en la wiki que
>> podamos tener de referencia en donde esté el total de calles de un
>> municipio frente a las que están mapeadas? De esta forma podríamos ver la
>> completitud del municipio en cuanto a los criterios que planteas y sería
>> mucho más cómodo distribuir a equipos de trabajo en cada una de las zonas,
>> para que revisen el nombre de sus calles.
>>
>> Un saludo!!!
>>
>> [1] http://www.callejerodeandalucia.es/
>>
>> El 23 de enero de 2016, 21:19, yo paseopor 
>> escribió:
>>
>>> ¡Buenas gente!
>>>
>>> Aunque mi ámbito habitual suele ser más la lista catalana, a veces me
>>> doy un garbeo por el grupo español de Telegram y comentando el desarrollo
>>> de un nuevo preset para una campaña de etiquetaje "básico" llegamos a la
>>> conclusión de que en ciertas zonas de España queda mucho por hacer. Así que
>>> me dispuse a comprobarlo un poco por encima, sin mucho esfuerzo. Usé
>>> http://qa.poole.ch/ Y estos son los resultados que cualquiera puede
>>> comprobar.
>>>
>>> De capitales de provincia las que requieren intervención urgente o
>>> similar:
>>> -Ourense
>>> -Cuenca
>>> *Madrid (la capital de España no puede tener calles sin nombrar, lo
>>> siento, es cuestión de imagen...lo mismo diría de Barcelona)
>>> -Toledo
>>> -Badajoz
>>> -Murcia
>>> -Jerez
>>>
>>> y los barrios exteriores y zonas nuevas de:
>>>
>>> -Tarragona
>>> -Almería
>>> -Sevilla
>>> -Cádiz
>>>
>>> Mención especial a Salamanca...vereis como la herramienta no le
>>> encuentra NINGÚN ERROR de NOName, un aplauso a los salmantinos y a quien
>>> edita en la zona ;)
>>>
>>> Como intervención en el grupo catalán de Telegram hemos debatido unos
>>> niveles que toda población debería tener, a fin de homogeneizar y mejorar
>>> el desarrollo del mapa:
>>>
>>> -Nivel 1: Trazado y nombre de calle
>>> -Nivel 2: Sentido de circulación, plazas,parques, lugares públicos y
>>> privados.
>>> -Nivel 3: Urbanizaciones, granjas,masías, usos del suelo (es lo que da
>>> color al mapa, residencial,comercial,industrial),delimitar correctamente
>>> límites administrativos.
>>>
>>> Para todo ello se piensa en el desarrollo de una predefinición de menú
>>> para JOSM que muestre las opciones dirigidas a esos niveles
>>> "básicos".También se comenta el envío de mensajes vía redes sociales a los
>>> ayuntamientos y comunidades de la zona para animar al uso y edición de OSM.
>>>
>>> -En el grupo 

Re: [Talk-it] il PCN risulta ostico?

[girarsi_liste]

Il 23/01/2016 19:07, girarsi_liste ha scritto:
> Risulta anche a voi oggi difficoltà ad avere il WMS del PCN 2006/12 oggi?
> 

Ieri il sito non andava e nemmeno il WMS, stamattina invece dalle 9:30
andava il sito e no il WMS, adesso nemmeno uno, risulta anche a voi?

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



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

Re: [Talk-it] il PCN risulta ostico?

[girarsi_liste]

Il 25/01/2016 11:36, girarsi_liste ha scritto:
> Il 23/01/2016 19:07, girarsi_liste ha scritto:
>> Risulta anche a voi oggi difficoltà ad avere il WMS del PCN 2006/12 oggi?
>>
> 
> Ieri il sito non andava e nemmeno il WMS, stamattina invece dalle 9:30
> andava il sito e no il WMS, adesso nemmeno uno, risulta anche a voi?
> 

Adesso il sito va di nuovo, notizie non ne vedo, però ragionando sul
servizio statistico[0], sembra che diano la precedenza ai servizi web 2D
e 3D.

http://www.pcn.minambiente.it/GN/statistiche-di-accesso-alla-cartografia-ita



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



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

Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers

[Andrew Davidson]

Yeap,  that's why my recipe had the json to kml step.  If you pull the kmz 
directly you have to strip off the ele tags and you also need to run the JOSM 
validator on the layer when you open it because every node seems to be 
duplicated.  Not only that, if there is more than one park that matches your 
query then you get them all and there is no indication of which is which. 

On 25 Jan 2016 16:01, Warin <61sundow...@gmail.com> wrote:
>
> On 25/01/2016 3:44 PM, Warin wrote:
>
> Well I have roughly follow this procedure on;
>
> for my previously entered 'Putty State Forest' relation 5806844 
> and newly entered 'Wollemi National Park' relation 5901253 
> These are large! .. 
> My past clickathon for the Putty state forest was some 800 nodes ... the data 
> there is now well over the 2,000 mark! Much more detail and accuracy - at 
> some data cost. 
>
> I got a .kml file from the website direct, thus avoiding the conversion. 
> BUT the JOSM simplification did not reduce the number of nodes! I will have 
> to do some thinking on it and play with it.  
>
> Arr found the problem.
> JOSM simplify will not touch any node with an elevation. The .klm files all 
> have elevations (0!) .. removing the elevation tag on the nodes is easy 
> find type=node .. and then delete the elevation tag .. does it for all of 
> them. 
>>
>>
>> Maybe I'll try just a section .. say way 393301771 and see if I can reduce 
>> its size. 
>>
>> On 24/01/2016 4:46 PM, Nev Wedding wrote:
>
> Your work flow using the geometries has worked very well for me with the LPI 
> data and the last bit regarding the merging each item separately into the 
> existing OSM data seems prudent and makes for easier management of the data.
> Much appreciated
> Nev 
>
>> On 24 Jan 2016, at 9:11 AM, Andrew Davidson  wrote:
>>
>> The work flow that JOSM wants you to use is to have your new data in one 
>> layer and the existing OSM data in another and to "merge selection" on 
>> individual items.  I'm assuming this is to slow down people just 
>> dump-and-running. I found it useful to use the merge approach as you can 
>> delete the ways from the kml layer as you do each one and it lets you check 
>> that you've processed each way. 
>>
>>
>>>
>>> - Original Message -
>>> From:
>>> "Nev Wedding" 
>>>
>>> To:
>>> "OSM Australian Talk List" 
>>> Cc:
>>>
>>> Sent:
>>> Sat, 23 Jan 2016 12:42:53 +1000
>>> Subject:
>>> Re: [talk-au] JOSM Scanaerial plugin on NSW LPI layers
>>>
>>>
>>> (corrected message….opening the .kml file
>>> I have the .kml file and the downloaded osm data as seperate layers and 
>>> want to upload the .kml layers which contains all the updated info)
>>>
>>> I have followed this process for Kooyong State Conservation Area which has 
>>> gone well after opening the .kml file and have simplified and added all the 
>>> tags, 
>>> …but on trying to upload the final boundary I get this ominous message
>>> “
>>> You are about to upload data from the layer 'Kooyong.kml'.
>>> Sending data from this layer is strongly discouraged. If you continue,
>>> it may require you subsequently have to revert your changes, or force other 
>>> contributors to.
>>> Are you sure you want to continue? 
>>> “
>>>
>>> I assume the warning is to dissuade mappers from careless import of large 
>>> uncorrected datasets.?
>>>
>>> Sooo…, am I ok to continue or is there another reason?  ..I am on-hold here 
>>> until I see a reply
>>>
>>> Nev 
>>>
>>>
 On 22 Jan 2016, at 11:36 PM, Andrew Davidson  wrote:

 You can extract the geometries from the database directly, you don't have 
 to scan them. I tried this on three park areas to see how much work was 
 involved. The recipe I followed was:

 1. Use the query tool to find out how many objects have the name that you 
 are looking for. You do this with:

 http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query

 with the return format set to html. Names must be in upper case and you 
 need to see what object ids are returned. For example if you search for 
 Yanununbeyan with:

 http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Administrative_Boundaries/MapServer/6/query?text=YANUNUNBEYAN==esriGeometryEnvelope==esriSpatialRelIntersects=false=false=truehtml

 You get three different ids (198,208,1131) because there is a Yanununbeyan 
 State Conservation Area, Yanununbeyan Nature Reserve, and Yanununbeyan 
 National Park. All of which need to be tagged differently. Follow the 
 object links to find out what type of area they are.

 2. Having found the object id you need you get the geometry by using the 
 query tool and setting the object id, setting the output spatial reference 
 to 4326 (WGS84), and changing the output format to JSON.

 3. Save the resulting page, 

Re: [OSM-talk-fr] Problème de langue

[Dominique Faure]

Ok, j'ai renommé le trajet en anglais:

  name=European route E 54

et profité pour corriger quelques sens de circulation.

Merci.



2016-01-25 11:01 GMT+01:00 Jérôme Seigneuret :

> Bonjour,
>
> J'ai vu le même problème pour les itinéraires Euro Vélo ... J'ai pas fait
> de modification. A moins de mettre le tag name en Anglais...
>
> Car cette alerte est à mon avis seulement valable pour les objets (node,
> way, relation) se limitant à un territoire dont la langue est identifié
> dans notre cas fr et non à des superpostion entre territoires
>
> Dans ton cas, la relation dépasse les frontières. Donc que choisir dans ce
> cas... Le name en Anglais, le name du pays de départ (qui soit disant
> passant est différent suivant le sens).
>
> J'aurais choisi un nom FR pour les tronçons en France un nom Allemand pour
> les tronçons Allemand et pour la relation (Euro), le nom en anglais et
> name:fr=* name:de=*
>
> le name:fr permet de toute manière de trouver cette relation dans Nominatim
>
> Jérôme
>
> Le 25 janvier 2016 à 10:40, Dominique Faure  a
> écrit :
>
>> Bonjour,
>>
>> "Jeune" contributeur d'OSM pour son quartier et alentours, j'ai pu me
>> débrouiller par mes propres moyens jusqu'à maintenant, mais là, j'avoue que
>> je sèche un peu...
>>
>> J'ai été amené à découper une rue en 2 (jusqu'en limite de commune) pour
>> lui redonner son nom et y rattacher quelques bâtiments dans une relation
>> associatedStreet.
>>
>> Depuis cette modification, j'ai ce message d'erreur dans osmose (
>> http://osmose.openstreetmap.fr/fr/byuser/Dfaure?level=1):
>>
>> =8<- - - - -
>> Noms dans la langue locale et dans la langue par défaut différents
>>
>> e-road:class = A-intermediate
>> name = Europastraße 54
>> name:de = Europastraße 54
>> name:fr = Route européenne 54
>> network = e-road
>> ref = E 54
>> route = road
>> type = route
>> wikidata = Q664865
>> wikipedia = fr:Route européenne 54
>> =8<- - - - -
>>
>> ​A noter que ma modification à eu lieu ici:
>> http://www.openstreetmap.org/way/391928538
>>
>>
>> Merci d'avance pour vos éclaircissements.
>> --
>> Dominique
>>
>> ___
>> 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
>
>


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