Re: [OSM-talk] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea (was: Re: [Geocoding] Boundries of Kardak Islands)

[Marc Gemis]

On Fri, Mar 31, 2017 at 6:39 AM, David Marchal  wrote:
> If I correctly remember, in such cases, both point of views should be used;
> in this case, two boundary segments should be dragged: one including the
> islets with Greece, and the other one including them with Turkey.

The rule is that border in OSM is where you have to show your passport
to the customs. Or where the barbed wire stands, or  whatever on the
ground fact indicates the presence of a border. The French-Italian
border which overlaps on the Mont-Blanc is not the preferred way
AFAIK.

m.

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

Re: [OSM-talk] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea (was: Re: [Geocoding] Boundries of Kardak Islands)

[David Marchal]

If I correctly remember, in such cases, both point of views should be used; in 
this case, two boundary segments should be dragged: one including the islets 
with Greece, and the other one including them with Turkey.

It has already been the case: for instance, the matter of the France-Italia 
border around the Mont-Blanc has never been truly solved: French maps says the 
summit is completely French, while Italian ones says the border crosses the 
summit. Even if the border, while unclear, is not really disputed, as both 
countries merely let it pass, the OSM management for such segment of border is 
that both point of views are displayed.

Anyway, as, in your case, the border is actively disputed, we should draw both; 
I understand that, as a Turk, you could not like that, but OSM must look beyond 
such disputes.

Regards.

Le 30 mars 2017 à 21:41, Florian Schäfer 
> a écrit :


Dear İlhami Özer,

These borders are disputed and the island is claimed by both Greece and Turkey.

There was a recent incident near the island in January: "A Turkish navy missile 
boat accompanied with two special-forces speedboats entered the area around the 
islets on 29 January 2017. According to the statement issued by the Defence 
Ministry of Greece, they were blocked and warned by Greek coast guard vessels 
and withdrew from the area after about seven minutes. The Turkish armed forces 
denied that the ships were blocked but did not otherwise deny the incident; 
they stated that the mission was a part of an inspection of the Aksaz Naval 
Base by chief of General Staff Hulusi Akar, who was on board at the time." 
(Source: Wikipedia article about the 
island)

You (I assume it's you, because of the similarity of your 
username and your real name and the 
proximity of time to your e-mail to the list) now changed the borders to 
reflect your point of view in this changeset yesterday: 
https://openstreetmap.org/changeset/47194531 .

I'm not an expert on borders and how disputed borders are handled in OSM, so I 
forward this to the talk-list, because this probably needs more discussion.

Regards,
Florian

Am 27.03.2017 um 10:36 schrieb ilhami özer:
Dear Openstreetmap valuable workers,

This situation is really important for us. The two islands are within 
bounderies of Turkey Republic. As you can see on the image which we sent 
attachment these two islands out of boundries of Turkey on your tile images. We 
did necessary changes on feature parts. Please can you make these changes on 
your basemap.

Kindly request.

--
İlhami ÖZER
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-us] Need Your Help!

[Dan Joseph]

Hi Moira,

For understanding OSM and the editors, there is a ton of information
available online.
The Missing Maps website links to some tutorial videos:
http://www.missingmaps.org/contribute/#learn

And LearnOSM has details for everyone from beginners to advanced:
http://learnosm.org/en/

The Missing Maps website, on the same page as the materials about hosting a
mapathon, also has a directory of people who have offered to help answer
questions about organizing mapathons. You could search the list and try
reaching out to a few: http://www.missingmaps.org/host/#helper-map-contents

Good luck with your mapathon. Great to see more people getting involved.

All the best,
Dan

On Mon, Mar 27, 2017 at 5:16 PM, moira walsh  wrote:

>
> Hello,
> I'm in StCloud, Minnesota.  I'm planning a Mapathon for April.  I need
> technical support, remote or on the ground.  Date and time are up to you.
> I need to decide on those as soon as possible, but have waited to ensure we
> can fit your time schedule.
>
> We'll be working on Missing Maps  http://tasks.hotosm.org/
> ?sort_by=priority=asc=eliminate+malaria.
> Please,
> Moira
> --
>
>
>
>
>
>
> Moira Walsh MPH
> www.waterinanutshell.net
> 507 210 6420 <(507)%20210-6420>   Texts are O.K.
>
> My emails come to you from gmail, but I ask that you send mail to this
> address moirawa...@tulanealumni.net.
> It will always forward to whatever email service I'm using.
> I am not sure how much longer I'll use gmail.
>
> ___
> 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

semanárioOSM Nº 349 21/03/2017-27/03/2017

[weeklyteam]

Bom dia,

O semanárioOSM Nº 349, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/8905/

Aproveite!

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

semanárioOSM Nº 349 21/03/2017-27/03/2017

[weeklyteam]

Bom dia,

O semanárioOSM Nº 349, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/8905/

Aproveite!

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

[OSM-talk-ie] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-GB] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-in] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-ca] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-us] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[talk-ph] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

[OSM-talk] weeklyOSM #349 21/03/2017-27/03/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[Jérôme Amagat]

Le 30 mars 2017 à 22:40,  a écrit :

> Effectivement, je n'avais pas pensé qu'il y a avait des relations farm.
>
> Même si le RGP est du déclaratif, c'est mieux que du CLC de 2006 (la
> Bretagne est particulièrement concernée par les terres agricoles mangées
> par les lotissements et autres zones industrielles). Alors un peu de
> procrastination en attendant la version 2016 ?
>
> > les bases d'occupation du sol des collectivités
>
> Bonne idée, par chez moi c'est de la donnée ouverte.
>
> > les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est
> que ça a été créer pour représenter des champs et pas un corps de ferme.
>
> Mais justement si on fait la différence ce n'est pas pour tout laisser
> dans le même sac. Et si on "corrige" ainsi, on n'aura plus d'alerte (sauf à
> faire des requêtes cherchant les bâtis sur une landuse=farmland). Je
> préfère garder le flou "zone d'agriculture" à la fausse précision "terres
> agricoles".
>

Pour moi le landuse=farm qui doit disparaître avait la même définition que
le landuse=farmland mais le problème était que farm pouvait être comprit
comme devant représenter une ferme ( batiment poulailler) Donc si le
tag a été bien interprété alors c'est juste de juste remplacer farm par
farmland. et donc comme une ferme a une dimension faible par rapport a
beaucoup de landuse=farm les plus grand sont des farmland si la personne
qui a mis le landuse=farm a fait ça correctement. Donc pas d'ajout d'erreur
en faisant comme j'ai dit. De tout repasser en revu un par un les farm
c'est donc vérifier ce qu'a fait une autre personne et donc pourquoi le
faire plus pour cela que pour autre chose.
Bon en fait la plupart on été ajouté par l'ajout massif du CLC mais c'est
pareil, pourquoi vérifié les farm et pas les forest ajouté en même temps.

Si il y en avait que quelques uns, je ne verrais pas de problème, mais là
il y en a beaucoup et donc dans quelques années il y en aura encore. Comme
les wood=*, les power=sub_station et bien d'autres.

Des endroit ou les import CLC sont pas terrible il y en a sur toute la
France, il y a surement 95% de la surface de la France qui mériterai qu'on
améliore les landuse alors pourquoi se rajouter des problèmes dans les
pattes.


Le RGP ça n'a rien non plus exceptionnel, les polygones ont été tracé par
les agriculteurs, il ne sont donc pas lié entre eux.
 ils regroupent leurs parcelles cote a cote et ils indique l'utilisation
principale de cette ensemble donc c'est pas parce que dans le RGP il y a
une parcelle indiqué champs de maïs que toute la parcelle est un champs de
maïs, il peut y avoir une partie pâturage, une autre colza, une autre
foret... Après ça dépend des zones, dans les zones de culture intensive ce
problème ne doit pas être très important mais dans d'autre si.


> Et dans l'autre sens : je veux bien, mais avec des champs qui alternent
> colza (*crop*=forage
> 
> ? les tourteaux sont plutôt de la nourriture animale mais le produit c'est
> plutôt de l'huile) et maïs (*produce*=maize
> )
> voir certaines années pâturage landuse
> =meadow
>  ça devient
> compliqué.
> Remarquer 3 clés différentes alors qu'il est toujours question de l'usage
> de la terre. Super pour les moteurs de rendu qui priviégieront toujours une
> clé.
>
> Sinon je ne vois pas comment indiquer un poulailler (qui est bien dans un
> farmyard ;-)).
> Le CLC, ça semble être aussi la première source de multi-polygones
> ancienne mode et la France a pris beaucoup de retard par rapport à
> l'Allemagne dans le nettoyage (visiblement il faut quelques personnes
> motivées).
>
> Jean-Yvon
>
> ___
> 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-ca] Telenav mapping turn restrictions

[Kevin Farrugia]

Well, if distances are similar but peed limits are different, the router
may prefer to go with the similar length route because it has a higher
speed limit.  Another case could be if the algorithm prefers the more major
road classification over the lower classified road in the hierarchy, it
could avoid the _link in order to satisfy it's hierarchy preferences.

-Kevin

On Mar 30, 2017 7:29 PM, "Ian Bruseker"  wrote:

> Kevin,
>
> That does make sense, but in the example Martijn gave, the starting point
> is well before the turning lane, so I'm picturing the car being there and
> the software still having time to make a choice which road to send it down.
> Why did OSRM pick to ignore the turning road given there is all the
> opportunity in the world to choose it instead of the actual intersection
> corner?
>
> Ian
>
>
>
> On Mar 30, 2017, at 5:19 PM, Kevin Farrugia 
> wrote:
>
> Hey Ian,
>
> The main purpose is to stop silly or dangerous things from happening. If a
> user misses their turn and the engine reroutes them to turn right where
> they shouldn't (or U-turn) the consequences could be catastrophic. When
> people are following a computer's instructions they'll follow them blindly
> (like when Michael drives his car into a lake in The Office).
>
> Plus if there's some weird error in the road topology or speed differences
> that could cause it to happen it's best to have them there as a catch.
>
> That's my view/reasoning from my experience working with routing and
> networks anyways.
>
> -Kevin (kevo)
>
>
> On Mar 30, 2017 7:02 PM, "Ian Bruseker"  wrote:
>
> Martijn,
>
> Can I ask what is possibly a really dumb question?  As stated earlier I'm
> not a lawyer, and really in truth I'm no cartographer either.  I generally
> stick to adding POIs for stores in local stripmalls, because that's not too
> dangerous to the map.  ;-)  Not being an expert in mapping, I probably just
> don't get why routing software works the way it does.  Why, in your example
> that you gave, would OSRM (or Scout) choose to send the user to the corner
> to turn at all?  I just don't get the logic of it.  The code seems pretty
> obvious (what I really am, after all, is a computer nerd).  In silly
> pseudocode: "if exists link-type road between current_location and
> destination, route via link road".  Why would it even look far enough ahead
> to see the corner to see whether there was a turn restriction or not, when
> there is already a more obvious path to take?  I mean, "obvious" to me as a
> human, I guess.  If I were driving down a road I'd never been to, and my
> passenger said "ok, take your next right", and I saw a turning
> lane/ramp/something, that's where I would go.  Shouldn't that be the
> routing software's first choice?  If it's looking far enough ahead on its
> path to even get to "you can't turn right here", then I would think its
> next step would be "ok, you can't turn right here, so I'll need to take
> them to the _next_ place they can turn right and route them back around the
> block to the road they want", not to then look backwards from the turn
> restriction to see if there was a linking road it could take instead.  The
> choice should have been made to take the linking road before it even cared
> whether it was allowed to turn them at the hard corner ahead, which would
> make putting the restrictions on the map for the purpose of "routing hint"
> sort of unnecessary, wouldn't it, if the software had just picked the
> correct route the first time?  Or worse, if they are there and the routing
> software hits them, wouldn't they then result in even longer routes,
> because once it got that far down the path, the only way to look is
> forward, which is a longer path?  I don't mean to tell you how to write
> your software. ;-)  Like I said, I don't actually know how routing software
> is coded.  And I'm sure you've considered this.  I'm just curious, given
> that consideration, _why_ would that route even happen in the first place
> (to take the hard corner rather than the link road)?
>
> Sorry if I'm derailing this discussion.  I don't touch the road network
> too much in my mapping unless I am pretty sure what I'm changing is
> obviously correct and simple, and I avoid weird intersections as much as
> possible.  I'm just curious to understand, so maybe in the future if I
> happen across such a situation, I'll have some idea how to map it so it
> doesn't send a driver making a dangerous turn or crashing through a fence
> or something.  ;-)
>
> Thanks,
> Ian
>
>
> On 30 March 2017 at 09:50, Martijn van Exel  wrote:
>
>> Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am
>> a little slow parsing French).
>>
>> First off thanks for your additional comments, they are really useful. I
>> realize that I should have shared more detail about what we are planning to
>> do and will do a better job in the future 

Re: [Talk-ca] Telenav mapping turn restrictions

[Ian Bruseker]

Kevin,

That does make sense, but in the example Martijn gave, the starting point is 
well before the turning lane, so I'm picturing the car being there and the 
software still having time to make a choice which road to send it down. Why did 
OSRM pick to ignore the turning road given there is all the opportunity in the 
world to choose it instead of the actual intersection corner?

Ian



> On Mar 30, 2017, at 5:19 PM, Kevin Farrugia  wrote:
> 
> Hey Ian,
> 
> The main purpose is to stop silly or dangerous things from happening. If a 
> user misses their turn and the engine reroutes them to turn right where they 
> shouldn't (or U-turn) the consequences could be catastrophic. When people are 
> following a computer's instructions they'll follow them blindly (like when 
> Michael drives his car into a lake in The Office).
> 
> Plus if there's some weird error in the road topology or speed differences 
> that could cause it to happen it's best to have them there as a catch.
> 
> That's my view/reasoning from my experience working with routing and networks 
> anyways.
> 
> -Kevin (kevo)
> 
> 
> On Mar 30, 2017 7:02 PM, "Ian Bruseker"  wrote:
> Martijn,
> 
> Can I ask what is possibly a really dumb question?  As stated earlier I'm not 
> a lawyer, and really in truth I'm no cartographer either.  I generally stick 
> to adding POIs for stores in local stripmalls, because that's not too 
> dangerous to the map.  ;-)  Not being an expert in mapping, I probably just 
> don't get why routing software works the way it does.  Why, in your example 
> that you gave, would OSRM (or Scout) choose to send the user to the corner to 
> turn at all?  I just don't get the logic of it.  The code seems pretty 
> obvious (what I really am, after all, is a computer nerd).  In silly 
> pseudocode: "if exists link-type road between current_location and 
> destination, route via link road".  Why would it even look far enough ahead 
> to see the corner to see whether there was a turn restriction or not, when 
> there is already a more obvious path to take?  I mean, "obvious" to me as a 
> human, I guess.  If I were driving down a road I'd never been to, and my 
> passenger said "ok, take your next right", and I saw a turning 
> lane/ramp/something, that's where I would go.  Shouldn't that be the routing 
> software's first choice?  If it's looking far enough ahead on its path to 
> even get to "you can't turn right here", then I would think its next step 
> would be "ok, you can't turn right here, so I'll need to take them to the 
> _next_ place they can turn right and route them back around the block to the 
> road they want", not to then look backwards from the turn restriction to see 
> if there was a linking road it could take instead.  The choice should have 
> been made to take the linking road before it even cared whether it was 
> allowed to turn them at the hard corner ahead, which would make putting the 
> restrictions on the map for the purpose of "routing hint" sort of 
> unnecessary, wouldn't it, if the software had just picked the correct route 
> the first time?  Or worse, if they are there and the routing software hits 
> them, wouldn't they then result in even longer routes, because once it got 
> that far down the path, the only way to look is forward, which is a longer 
> path?  I don't mean to tell you how to write your software. ;-)  Like I said, 
> I don't actually know how routing software is coded.  And I'm sure you've 
> considered this.  I'm just curious, given that consideration, _why_ would 
> that route even happen in the first place (to take the hard corner rather 
> than the link road)?
> 
> Sorry if I'm derailing this discussion.  I don't touch the road network too 
> much in my mapping unless I am pretty sure what I'm changing is obviously 
> correct and simple, and I avoid weird intersections as much as possible.  I'm 
> just curious to understand, so maybe in the future if I happen across such a 
> situation, I'll have some idea how to map it so it doesn't send a driver 
> making a dangerous turn or crashing through a fence or something.  ;-)
> 
> Thanks,
> Ian
> 
> 
>> On 30 March 2017 at 09:50, Martijn van Exel  wrote:
>> Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a 
>> little slow parsing French).
>> 
>> First off thanks for your additional comments, they are really useful. I 
>> realize that I should have shared more detail about what we are planning to 
>> do and will do a better job in the future if new projects arise. We are 
>> actually working on a Github repository (similar to Mapbox's) where we will 
>> share more details about mapping projects and where everybody will be able 
>> to talk to the team about what we do. Of course we will continue to post 
>> here as well.
>> 
>> We do have a serious onboarding process for new mappers on our team where 
>> more experienced mappers guide the 

Re: [Talk-ca] Telenav mapping turn restrictions

[Kevin Farrugia]

Hey Ian,

The main purpose is to stop silly or dangerous things from happening. If a
user misses their turn and the engine reroutes them to turn right where
they shouldn't (or U-turn) the consequences could be catastrophic. When
people are following a computer's instructions they'll follow them blindly
(like when Michael drives his car into a lake in The Office).

Plus if there's some weird error in the road topology or speed differences
that could cause it to happen it's best to have them there as a catch.

That's my view/reasoning from my experience working with routing and
networks anyways.

-Kevin (kevo)


On Mar 30, 2017 7:02 PM, "Ian Bruseker"  wrote:

Martijn,

Can I ask what is possibly a really dumb question?  As stated earlier I'm
not a lawyer, and really in truth I'm no cartographer either.  I generally
stick to adding POIs for stores in local stripmalls, because that's not too
dangerous to the map.  ;-)  Not being an expert in mapping, I probably just
don't get why routing software works the way it does.  Why, in your example
that you gave, would OSRM (or Scout) choose to send the user to the corner
to turn at all?  I just don't get the logic of it.  The code seems pretty
obvious (what I really am, after all, is a computer nerd).  In silly
pseudocode: "if exists link-type road between current_location and
destination, route via link road".  Why would it even look far enough ahead
to see the corner to see whether there was a turn restriction or not, when
there is already a more obvious path to take?  I mean, "obvious" to me as a
human, I guess.  If I were driving down a road I'd never been to, and my
passenger said "ok, take your next right", and I saw a turning
lane/ramp/something, that's where I would go.  Shouldn't that be the
routing software's first choice?  If it's looking far enough ahead on its
path to even get to "you can't turn right here", then I would think its
next step would be "ok, you can't turn right here, so I'll need to take
them to the _next_ place they can turn right and route them back around the
block to the road they want", not to then look backwards from the turn
restriction to see if there was a linking road it could take instead.  The
choice should have been made to take the linking road before it even cared
whether it was allowed to turn them at the hard corner ahead, which would
make putting the restrictions on the map for the purpose of "routing hint"
sort of unnecessary, wouldn't it, if the software had just picked the
correct route the first time?  Or worse, if they are there and the routing
software hits them, wouldn't they then result in even longer routes,
because once it got that far down the path, the only way to look is
forward, which is a longer path?  I don't mean to tell you how to write
your software. ;-)  Like I said, I don't actually know how routing software
is coded.  And I'm sure you've considered this.  I'm just curious, given
that consideration, _why_ would that route even happen in the first place
(to take the hard corner rather than the link road)?

Sorry if I'm derailing this discussion.  I don't touch the road network too
much in my mapping unless I am pretty sure what I'm changing is obviously
correct and simple, and I avoid weird intersections as much as possible.
I'm just curious to understand, so maybe in the future if I happen across
such a situation, I'll have some idea how to map it so it doesn't send a
driver making a dangerous turn or crashing through a fence or something.
 ;-)

Thanks,
Ian


On 30 March 2017 at 09:50, Martijn van Exel  wrote:

> Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a
> little slow parsing French).
>
> First off thanks for your additional comments, they are really useful. I
> realize that I should have shared more detail about what we are planning to
> do and will do a better job in the future if new projects arise. We are
> actually working on a Github repository (similar to Mapbox's) where we will
> share more details about mapping projects and where everybody will be able
> to talk to the team about what we do. Of course we will continue to post
> here as well.
>
> We do have a serious onboarding process for new mappers on our team where
> more experienced mappers guide the newcomers and introduce them to the OSM
> ecosystem. So they are not quite thrown in the deep end, but like everybody
> else they go through a learning process where they make simple edits first.
> We don't ever use live OSM data for pilot or test projects.
>
> I don't feel there's a consensus about the turn restrictions in places
> where they are not marked. There are really good (routing / safety related)
> reasons for this as I pointed out before [1] and in my research I have
> found many of these in the U.S. as well, but until that is cleared up we
> will not add any more. This includes the left turn restrictions Pierre
> mentioned. To Pierre's comments, I don't 

Re: [Talk-ca] Telenav mapping turn restrictions

[Ian Bruseker]

Martijn,

Can I ask what is possibly a really dumb question?  As stated earlier I'm
not a lawyer, and really in truth I'm no cartographer either.  I generally
stick to adding POIs for stores in local stripmalls, because that's not too
dangerous to the map.  ;-)  Not being an expert in mapping, I probably just
don't get why routing software works the way it does.  Why, in your example
that you gave, would OSRM (or Scout) choose to send the user to the corner
to turn at all?  I just don't get the logic of it.  The code seems pretty
obvious (what I really am, after all, is a computer nerd).  In silly
pseudocode: "if exists link-type road between current_location and
destination, route via link road".  Why would it even look far enough ahead
to see the corner to see whether there was a turn restriction or not, when
there is already a more obvious path to take?  I mean, "obvious" to me as a
human, I guess.  If I were driving down a road I'd never been to, and my
passenger said "ok, take your next right", and I saw a turning
lane/ramp/something, that's where I would go.  Shouldn't that be the
routing software's first choice?  If it's looking far enough ahead on its
path to even get to "you can't turn right here", then I would think its
next step would be "ok, you can't turn right here, so I'll need to take
them to the _next_ place they can turn right and route them back around the
block to the road they want", not to then look backwards from the turn
restriction to see if there was a linking road it could take instead.  The
choice should have been made to take the linking road before it even cared
whether it was allowed to turn them at the hard corner ahead, which would
make putting the restrictions on the map for the purpose of "routing hint"
sort of unnecessary, wouldn't it, if the software had just picked the
correct route the first time?  Or worse, if they are there and the routing
software hits them, wouldn't they then result in even longer routes,
because once it got that far down the path, the only way to look is
forward, which is a longer path?  I don't mean to tell you how to write
your software. ;-)  Like I said, I don't actually know how routing software
is coded.  And I'm sure you've considered this.  I'm just curious, given
that consideration, _why_ would that route even happen in the first place
(to take the hard corner rather than the link road)?

Sorry if I'm derailing this discussion.  I don't touch the road network too
much in my mapping unless I am pretty sure what I'm changing is obviously
correct and simple, and I avoid weird intersections as much as possible.
I'm just curious to understand, so maybe in the future if I happen across
such a situation, I'll have some idea how to map it so it doesn't send a
driver making a dangerous turn or crashing through a fence or something.
 ;-)

Thanks,
Ian


On 30 March 2017 at 09:50, Martijn van Exel  wrote:

> Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a
> little slow parsing French).
>
> First off thanks for your additional comments, they are really useful. I
> realize that I should have shared more detail about what we are planning to
> do and will do a better job in the future if new projects arise. We are
> actually working on a Github repository (similar to Mapbox's) where we will
> share more details about mapping projects and where everybody will be able
> to talk to the team about what we do. Of course we will continue to post
> here as well.
>
> We do have a serious onboarding process for new mappers on our team where
> more experienced mappers guide the newcomers and introduce them to the OSM
> ecosystem. So they are not quite thrown in the deep end, but like everybody
> else they go through a learning process where they make simple edits first.
> We don't ever use live OSM data for pilot or test projects.
>
> I don't feel there's a consensus about the turn restrictions in places
> where they are not marked. There are really good (routing / safety related)
> reasons for this as I pointed out before [1] and in my research I have
> found many of these in the U.S. as well, but until that is cleared up we
> will not add any more. This includes the left turn restrictions Pierre
> mentioned. To Pierre's comments, I don't think that there's really an
> easier way to map this, turn restrictions have been discussed in the
> community at length and other solutions not based on relations just don't
> scale well to complex situations.
>
> The Bing imagery alignment issue is one that we have not given proper
> attention and I will impress upon the team that they should pay really
> close attention to this and be even more restrained in modifying local
> mappers' work. I seem to remember there is a site / place that lists offset
> issues with Bing imagery by region? Is there a good source to look at for
> this?
>
> I'm thinking it would be good to hold an online town hall where some of
> our team members and 

Re: [Talk-at] Vorsicht Falle in: fire_hydrant:flow_capacity

[Walter Nordmann]

Hi Borut,



Am 30.03.2017 um 23:07 schrieb Borut Maricic:

In meinen Augen ist das absolute Vorteil Deiner Anwendung
deren Aktualität. Falls es Dir möglich wäre, in ein paar Sätzen
die Architektur hier zu beschreiben (ich bin halt neugierig,
will aber lieber nicht in die Source eintauchen) - vor allem
bezüglich des Lag-Zeit Zählers - wäre ich Dankbar.
Ich habe einen Full-Planet online, den ich per Diffs aktuell halte. 
(osmosis + osm2pgsql). Und mein neuer Server ist so performant, dass das 
Lag i.d.R. 2 Minuten nicht überschreitet. 
https://wambachers-osm.website/index.php/technisches-umfeld


Den Lag bekomme ich, indem ich 1x pro Minute das aktuelle state.txt 
auswerte. Dass der Counter 1x pro Sekunde hochzählt, ist einfaches 
Javascript.


  getOsmReplicationLag();
  setInterval(getOsmReplicationLag,6);
  setInterval(LagAnzeigen,1000);

wenn dir das alles was sagt und du noch Fragen hast, melde dich ruhig.


Ich glaube, dass man in der OpenFireMap die einzelnen
Feuerwehr-Objekte anklicken kann, um dessen Details
dargestellt zu bekommen. Eigentlich fehlt mir diese
Möglichkeit in der EmergencyMap (oder habe ich das nicht
richtig bekommen, oder passt mein Browser nicht ganz dazu).
Natürlich geht das auch. Allerdings erst seit ca 1 Woche. Probiere es 
einfach nochmal aus.


In der Pipeline sind Cluster, da das doch zu viele Objekte auf der Karte 
sind.


Gruss
walter

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

Re: [Talk-at] Vorsicht Falle in: fire_hydrant:flow_capacity

[Borut Maricic]

Hallo Walter!

Wenn ich etwas dazu sagen darf... Eigentlich hast
ausgerechnet Du, ohne es zu wissen, diese aktuelle
Feuerwehr-Diskussion durch Deine EmergencyMap ausgelöst und
kannst stolz darauf sein :) - In der Wochennotiz 347 wurde
davon berichtet und ich habe diese Information durch private
Nachrichten ein bisschen verbreitet. Danach sind die
Ereignisse in Gang gekommen... Auf der von mir früher
erwähnten Stammtisch-Seite gibt es einige Links auf
EmergencyMap, die ein paar Gegenden der Obersteiermark
darstellen.

In meinen Augen ist das absolute Vorteil Deiner Anwendung
deren Aktualität. Falls es Dir möglich wäre, in ein paar Sätzen
die Architektur hier zu beschreiben (ich bin halt neugierig,
will aber lieber nicht in die Source eintauchen) - vor allem
bezüglich des Lag-Zeit Zählers - wäre ich Dankbar.

Ich glaube, dass man in der OpenFireMap die einzelnen
Feuerwehr-Objekte anklicken kann, um dessen Details
dargestellt zu bekommen. Eigentlich fehlt mir diese
Möglichkeit in der EmergencyMap (oder habe ich das nicht
richtig bekommen, oder passt mein Browser nicht ganz dazu).

Also, vielen Dank für die, aus meiner Sicht, extrem tolle
Anwendung!

Liebe Grüße aus der Obersteiermark,
Borut

2017-03-30 22:18:12 Walter Nordmann (wnordm...@gmx.de):

> Hi Charly

> zu deiner Frage kann ich relativ wenig sagen (haben die Kollegen ja
> bereist erledigt) nur schau mal hierhin:

> https://wambachers-osm.website/emergency ist eine Alternative zur
> OpenFireMap.

> Gruss
> walter

> ps: Ja, das ist mein Baby.


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


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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[osm . sanspourriel]

Effectivement, je n'avais pas pensé qu'il y a avait des relations farm.

Même si le RGP est du déclaratif, c'est mieux que du CLC de 2006 (la 
Bretagne est particulièrement concernée par les terres agricoles mangées 
par les lotissements et autres zones industrielles). Alors un peu de 
procrastination en attendant la version 2016 ?


> les bases d'occupation du sol des collectivités

Bonne idée, par chez moi c'est de la donnée ouverte.

> les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est 
que ça a été créer pour représenter des champs et pas un corps de ferme.


Mais justement si on fait la différence ce n'est pas pour tout laisser 
dans le même sac. Et si on "corrige" ainsi, on n'aura plus d'alerte 
(sauf à faire des requêtes cherchant les bâtis sur une 
landuse=farmland). Je préfère garder le flou "zone d'agriculture" à la 
fausse précision "terres agricoles".


Et dans l'autre sens : je veux bien, mais avec des champs qui alternent 
colza (*crop*=forage 
 
? les tourteaux sont plutôt de la nourriture animale mais le produit 
c'est plutôt de l'huile) et maïs (*produce*=maize 
) 
voir certaines années pâturage landuse 
=meadow 
 ça devient 
compliqué.
Remarquer 3 clés différentes alors qu'il est toujours question de 
l'usage de la terre. Super pour les moteurs de rendu qui priviégieront 
toujours une clé.


Sinon je ne vois pas comment indiquer un poulailler (qui est bien dans 
un farmyard ;-)).


Le CLC, ça semble être aussi la première source de multi-polygones 
ancienne mode et la France a pris beaucoup de retard par rapport à 
l'Allemagne dans le nettoyage (visiblement il faut quelques personnes 
motivées).


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

Re: [OSM-talk-fr] Nomino en panne ?

[Christian Rogel]

Le 2017 Meur. 30 à 21:06, osm.sanspourr...@spamgourmet.com a écrit :
> 
> http://nominatim.openstreetmap.org 
> Je ne connaissais pas Nomino, mais Nominatim fait à peu près la même chose, 
> non ?
> 
> Le 30/03/2017 à 17:31, Christian Rogel - christian.ro...@club-internet.fr 
>  a écrit :
>> Bonjour, 
>> 
>> Quand je cherche un toponyme avec Nomino : https://nomino.openstreetmap.fr/ 
>>  et que je clique sur un élément de ce qui 
>> est retourné, j’obtiens "invalid object ».
>> 
>> Une solution en vue ?


Non, Nominatim et Nomino n’ont pas le même usage.
Le second est dédié à localiser les toponymes et autres POI dans les 2 sens du 
mot :
les trouver sur la carte
leur affecter un « name: {code ISO 639} »  pour d’autres langues
C’est particulièrement utile pour insérer les versions en breton de toponymes, 
validées ou non, par l’Office public de la langue bretonne.

Il sert beaucoup à des transcriptions alphabétiques ou idéographiques.


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

Re: [Talk-at] Vorsicht Falle in: fire_hydrant:flow_capacity

[Walter Nordmann]

Hi Charly

zu deiner Frage kann ich relativ wenig sagen (haben die Kollegen ja 
bereist erledigt) nur schau mal hierhin:


https://wambachers-osm.website/emergency ist eine Alternative zur 
OpenFireMap.


Gruss
walter

ps: Ja, das ist mein Baby.


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

[OSM-talk] Disputed border between Greece and Turkey near Imia/Kardak in the Aegean Sea (was: Re: [Geocoding] Boundries of Kardak Islands)

[Florian Schäfer]

Dear İlhami Özer,

These borders are disputed and the island is claimed by both Greece and
Turkey.

There was a recent incident near the island in January: "A Turkish navy
missile boat accompanied with two special-forces speedboats entered the
area around the islets on 29 January 2017. According to the statement
issued by the Defence Ministry of Greece, they were blocked and warned
by Greek coast guard vessels and withdrew from the area after about
seven minutes. The Turkish armed forces denied that the ships were
blocked but did not otherwise deny the incident; they stated that the
mission was a part of an inspection of the Aksaz Naval Base by chief of
General Staff Hulusi Akar, who was on board at the time." (Source:
Wikipedia article about the island
)

You (I assume it's you, because of the similarity of your username
 and your real name and the
proximity of time to your e-mail to the list) now changed the borders to
reflect your point of view in this changeset yesterday:
https://openstreetmap.org/changeset/47194531 .

I'm not an expert on borders and how disputed borders are handled in
OSM, so I forward this to the talk-list, because this probably needs
more discussion.

Regards,
Florian

Am 27.03.2017 um 10:36 schrieb ilhami özer:
> Dear Openstreetmap valuable workers,
>
> This situation is really important for us. The two islands are within
> bounderies of Turkey Republic. As you can see on the image which we
> sent attachment these two islands out of boundries of Turkey on your
> tile images. We did necessary changes on feature parts. Please can you
> make these changes on your basemap.
>
> Kindly request.
>
> -- 
> İlhami ÖZER 


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

Re: [OSM-talk-fr] Relation type=route étrange

[jabali]

Bonsoir,
1 - Pour la Roche/Yon - La Rochelle -J'ai jeté un oeil et il s'agit
effectivement d'une "collection" des infrastructures vélo du coin.
Rien à voir avec la moindre notion d'itinéraire, encore moins de vélo route.
Typiquement un mapping erroné pour faire ressortir les infrastructures en
couleur sur un rendu.
Pour moi, à supprimer sans hésiter.

2 - Pour Oléron-Ré : Il est possible qu'il y ait sur place une signalétique
directionnelle vélo.
Le réseau semble plus cohérent et la zone est touristique.
Pas de vélo-route à proprement parlé mais des panneaux vélo qui indiquent
des tronçons intervillages Bike-friendly. Ce peut être des petites
unclassified comme chemins forestiers.
Dans ce cas  l'usage veut que l'on utilise pas de relation route. (ce ne
sont pas des vélo-routes) mais le tag
/lcn=yes/ sur chaque ways indiqué par cette signalétique.
En plus, c'est rendu  sur OpenCycleMap


Il y a de nombreux exemples sur Strasbourg 
https://www.openstreetmap.org/way/370837858
https://www.openstreetmap.org/way/43053811
https://www.openstreetmap.org/way/372356217

ou en Allemagne ou cette signalisation est très courante.
https://www.openstreetmap.org/way/191229314#map=13/48.0132/7.8132=C

Néanmoins, la tentation de regrouper ce réseau dans des relations de type
velo-route existe et crée des polémiques également outre-rhin.
https://www.openstreetmap.org/way/191229314#map=13/48.0132/7.8132=C

En ce qui me concerne c'est lcn=yes.(si il y a une signalétique bien-sûr)
Je reserve les routes=bicycle aux vélo-route.
l'équivalent cycle des GR GRP PR 






--
View this message in context: 
http://gis.19327.n8.nabble.com/Relation-type-route-etrange-tp5894441p5894461.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] [administrivia][osmveneto] Creazione nuova lista regionale del Veneto

[lomastrolo]

Il giorno gio, 30/03/2017 alle 20.48 +0200, Luca 'remix_tj' Lorenzetto
ha scritto:
> Ciao a tutti,
> 
> fino a poco meno di un mesetto fa la ML osmveneto utilizzata come
> lista regionale per il Veneto era ospitata sul mio server personale.
> Un brutto tiro dell'hoster, una mia disattenzione e una serie di
> sfighe conseguenti ha fatto si che perdessi buona parte di quello che
> avevo su quel server. Tra le cose che ho perso sono i dati della ML.
> Gli archivi li posso recuperare rapidamente (ho tutte le mail), ma la
> lista degli iscritti mi manca.
> 
> Volevo quindi approfittare dell'occasione per migrare i dati su
> un'infrastruttura più solida come quella della fondazione.
> 
> Qualcuno sa a chi ci si deve rivolgere?
> 
> Grazie,
> 
> Luca
> 

Puoi chiedere a Michael Collinson
https://www.openstreetmap.org/user/MichaelCollinson


Trovi la sua mail qui:
https://wiki.openstreetmap.org/wiki/Mailing_lists


Lorenzo

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

Re: [Talk-at] Verwendung von Multipolygonen

[grubernd]

On 2017-03-30 15:43, jdz5...@gmx.at wrote:

Bei der (wieder einmal) intensiven Beschäftigung mit Multipolygonen sind mir - 
abseits der Geometrie - einige fragwürdige Verwendungen aufgefallen. Dazu ein 
paar hoffentlich hilfreiche Fragen und Beispiele (aus Österreich).

Grundsätzlich: eine Multipolygon-Relation [1] (MPR) statt eines Polygons 
(geschlossene Linie) braucht es
a) wenn eine Fläche ein Loch hat
b) wenn die Grenze der Fläche aus mehr als einer Linie besteht (im Weiteren 
nicht von Bedeutung)

Tags an der Relation beziehen sich auf diese, Tags an den Innen/Außenlinien 
gelten unabhängig davon für diese Linien und können zusätzliche Flächen 
begründen [2].



nachdem ich neulich mein erstes reales Multipolygon gesplittet [1] und 
mich im Vorfeld mit dem Thema intensiver auseinandergesetzt habe, hier 
meine Sicht der Dinge dazu.


MPR sind ein Konstrukt wenn es sich um exklusive Flächen handelt. also 
grob alles was unter "landuse" und Konsorten fällt.


forest/meadow/farmland sowie See, Insel, usw etc
residential/industrial

ich versuche das Grundtag (forest) auf die Relation zu setzen und alle 
"inner" (zB meadow) bekommen ihr eigenes Tag _bevor_ ich sie in die 
Relation einbaue. das erhöht die Mobilität der einzelnen Elemente wenn 
mal was umgebaut werden muss.


und das wars dann eigentlich auch schon.


die (osm-) Welt wäre einfacher wenn es diesen – meiner Meinung nach – 
Blödsinn der Multipolygone nicht gäbe. es gibt nichts was man nicht mit 
einer klaren Tesselierung darstellen könnte, leider wurde dieses viel 
einfacher zu handhabende Flächenmodell nicht verwendet, wahrscheinlich 
um gerade in den Anfangstagen Datenvolumen in der Datenbank einzusparen.


das hat nichts mit der Notwendigkeit von Relationen zB für Strassen, 
Wanderwege, Buslinien usw zu tun!



grüsse,
grubernd

[1] http://www.openstreetmap.org/changeset/46877554

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

Re: [OSM-talk] it may be useful

[Lester Caine]

On 30/03/17 19:47, Lester Caine wrote:
> On 30/03/17 18:38, Lester Caine wrote:
>> Kind regards, Lester Caine
> 
> *I* did not sent that email! Which is why it has another email address
> since forging my own would fall fowl of my spf record!

OK anybody know who to report 'The Brit Method' website to for forging
other peoples details to spam via groups. SEVEN different copies of the
same crap with my name on across a number of lists, and I see they are
using other list members details as well ... I will not publish their
real web address as that just plays to their tactics :(

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

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

Re: [OSM-talk-fr] Nomino en panne ?

[osm . sanspourriel]

http://nominatim.openstreetmap.org

Je ne connaissais pas Nomino, mais Nominatim fait à peu près la même 
chose, non ?



Le 30/03/2017 à 17:31, Christian Rogel - 
christian.ro...@club-internet.fr a écrit :

Bonjour,

Quand je cherche un toponyme avec Nomino : 
https://nomino.openstreetmap.fr/ et que je clique sur un élément de ce 
qui est retourné, j’obtiens "invalid object ».


Une solution en vue ?


Christian R.


___
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] Relation type=route étrange

[Philippe Verdy]

Déjà le nom avec des "underscores" au lieu des espaces, comme si le but
était de ne pas confondre avec le nom de la commune alors que c'est bel et
bien une indication des pistes cyclables présentes sur la commune, mais pas
un réseau en tant que tel (la commune n'a pas en charge elle-même toutes
ces voiries), ça doit ressembler plutôt à la reprise d'un plan
d'information fourni par l'office de tourisme et inon je ne vois pas
pourquoi certaines routes sont coupées juste à la limite de la commune,
alors que d'évidence il ne s'agit que de petits tronçons locaux de routes
plus longues.
Même la "ref" indiquée est fausse (elle reprend le nom complet de la
commune) de toute façon ce ne sons pas des "routees", à la limite un
"réseau" mais le réseau indiqué (lcn) n'est pas celui-là et le nom de la
commune n'est pas le nom du réseau "lcn".

Le 30 mars 2017 à 17:37, Charles MILLET  a écrit :

> Bonjour,
>
> J'ai remarqué des relations d'itinéraire cyclable qui me paraissent
> inadapté aux modèles acceptés ; exemples :
>
> https://www.openstreetmap.org/relation/6605742
>
> https://www.openstreetmap.org/relation/6486383
>
> On dirait que l'objectif est plus d'avoir un rendu des pistes cyclables
> d'une agglomération ou d'une grande ville mise en valeur dans des outils
> tels que waymarkedtrails.org
>
> J'ai contacté à deux reprise la personne qui les a créée pour lui proposer
> d'autres moyens d'afficher les pistes cyclables d'une villes ou d'une agglo
> et en expliquant qu'à ma connaissance les relations de type route ne sont
> pas adaptées à ce type d'objectif... Je n'ai pas eu de réponse :\
>
> J'ai deux questions :
>
> – Est-ce que vous pensez qu'effectivement il ne s'agit pas d'itinéraires
> et que les relations d'OSM n'ont pas (encore) vocation à contenir ce type
> d'information ?
>
> – Qu'est-ce qu'on fait dans cette situation ? Est-ce qu'on supprime la
> relation ?
>
> À bientôt.
>
>
> --
> Charles MILLET
> charlesmil...@free.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-it] [civici Torino] Offset generale

[Cascafico Giovanni]

Il comune di Torino ha pubblicato direttamente in coordinate geodetiche,
suppongo WGS84.



Il giorno 30 marzo 2017 19:19, Paolo Monegato  ha
scritto:

> Il 29/03/2017 18:36, Volker Schmidt ha scritto:
>
>> Cari amici,
>>
>> ho paura che questo è solo l'ennesima manifestazione dello stesso errore
>> sistematico con tutti gli import fatti finora in Veneto.(edifici e landuse).
>>
>
> Beh sarebbe anche normale,... se il dato di partenza è in Roma 40 va da se
> che riproiettandolo con i sistemi che liberamente e legalmente possiamo
> usare risulterà un offset in varie direzioni a seconda dell'area...
>
> ciao
>
> Paolo M
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] it may be useful

[Lester Caine]

On 30/03/17 18:38, Lester Caine wrote:
> Kind regards, Lester Caine

*I* did not sent that email! Which is why it has another email address
since forging my own would fall fowl of my spf record!

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

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

[Talk-it] [administrivia][osmveneto] Creazione nuova lista regionale del Veneto

[Luca 'remix_tj' Lorenzetto]

Ciao a tutti,

fino a poco meno di un mesetto fa la ML osmveneto utilizzata come
lista regionale per il Veneto era ospitata sul mio server personale.
Un brutto tiro dell'hoster, una mia disattenzione e una serie di
sfighe conseguenti ha fatto si che perdessi buona parte di quello che
avevo su quel server. Tra le cose che ho perso sono i dati della ML.
Gli archivi li posso recuperare rapidamente (ho tutte le mail), ma la
lista degli iscritti mi manca.

Volevo quindi approfittare dell'occasione per migrare i dati su
un'infrastruttura più solida come quella della fondazione.

Qualcuno sa a chi ci si deve rivolgere?

Grazie,

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 

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

Re: [Talk-it] [civici Torino] Offset generale

[Volker Schmidt]

... e suppongo per questo motivo è stato scritto nello istruzioni per
import che ogni pezzo deve essere allineato a PCN2006 primo dell'import
definitivo.

On 30 Mar 2017 19:20, "Paolo Monegato"  wrote:

> Il 29/03/2017 18:36, Volker Schmidt ha scritto:
>
>> Cari amici,
>>
>> ho paura che questo è solo l'ennesima manifestazione dello stesso errore
>> sistematico con tutti gli import fatti finora in Veneto.(edifici e landuse).
>>
>
> Beh sarebbe anche normale,... se il dato di partenza è in Roma 40 va da se
> che riproiettandolo con i sistemi che liberamente e legalmente possiamo
> usare risulterà un offset in varie direzioni a seconda dell'area...
>
> ciao
>
> Paolo M
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Telenav mapping turn restrictions

[Pierre Béland]

Bonjour Martijn
Le problème de navigation que tu mentionnes ne s'explique pas par les données 
OSM. Vous tentatives de régler ces problèmes des logiciels de navigation 
alourdissent inutilement la base OSM. Les cles turn peuvent souvent etre 
utilisées et sont moins complexes que les relations de restriction - voir 
exemples

The navigation problem you present is not due to OSM data. The fixes for 
software navigation problems make the database unecessary more complex, 
especially with restriction relations - See examples.

way=385943816, relation no left turn , junction to a oneway - Why ?
way=385943815, relation no left turn, turn=through key would be simpler

your routing example to turn right, the routing software skips the primary 
link. Why ?
way=172236000, primary link well connected -> routing software problem to fix 
first ?
More routing examples around:
routing software accepts the previous primary link to turn right
https://www.openstreetmap.org/directions?engine=mapzen_car=40.66632%2C-111.86855%3B40.66532%2C-111.86682#map=18/40.66579/-111.86688

routing software accepts to turn left even if a restriction relation on turn 
leftway=385943814, relation 5743391, restriction no left 
turnhttps://www.openstreetmap.org/directions?engine=mapzen_car=40.66632%2C-111.86855%3B40.66641%2C-111.86492#map=18/40.66600/-111.86668

In the opposite direction, the software accepts to turn left on the primary 
linkhttps://www.openstreetmap.org/directions?engine=mapzen_car=40.66503%2C-111.86237%3B40.66532%2C-111.86682#map=17/40.66552/-111.86460
And worst, the software accepts to make a u-turn on the primary links - 
probably adding a simple key turn=through would fix this.
https://www.openstreetmap.org/directions?engine=mapzen_car=40.66503%2C-111.86237%3B40.66608%2C-111.86699#map=18/40.66574/-111.86540
 Pierre 


  De : Martijn van Exel 
 À : Andrew Lester  
Cc : talk-ca 
 Envoyé le : jeudi 30 mars 2017 11h51
 Objet : Re: [Talk-ca] Telenav mapping turn restrictions
   
Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a 
little slow parsing French).
First off thanks for your additional comments, they are really useful. I 
realize that I should have shared more detail about what we are planning to do 
and will do a better job in the future if new projects arise. We are actually 
working on a Github repository (similar to Mapbox's) where we will share more 
details about mapping projects and where everybody will be able to talk to the 
team about what we do. Of course we will continue to post here as well.
We do have a serious onboarding process for new mappers on our team where more 
experienced mappers guide the newcomers and introduce them to the OSM 
ecosystem. So they are not quite thrown in the deep end, but like everybody 
else they go through a learning process where they make simple edits first. We 
don't ever use live OSM data for pilot or test projects.
I don't feel there's a consensus about the turn restrictions in places where 
they are not marked. There are really good (routing / safety related) reasons 
for this as I pointed out before [1] and in my research I have found many of 
these in the U.S. as well, but until that is cleared up we will not add any 
more. This includes the left turn restrictions Pierre mentioned. To Pierre's 
comments, I don't think that there's really an easier way to map this, turn 
restrictions have been discussed in the community at length and other solutions 
not based on relations just don't scale well to complex situations.
The Bing imagery alignment issue is one that we have not given proper attention 
and I will impress upon the team that they should pay really close attention to 
this and be even more restrained in modifying local mappers' work. I seem to 
remember there is a site / place that lists offset issues with Bing imagery by 
region? Is there a good source to look at for this?
I'm thinking it would be good to hold an online town hall where some of our 
team members and myself can answer any questions and discuss the issues raised? 
If you're interested in this let me know off-list and we can set up a time.
Thanks again for your feedback and willingness to work on this with me and the 
team. We really do want to improve the map for everyone and we will be taking 
this as an opportunity to do significantly better.
Martijn
[1] Look for example at this situation where there is no turn restriction on an 
intersection with a _link road and OSRM does not route over the _link road. 
https://www.openstreetmap.org/directions?engine=osrm_car=40.66610%2C-111.86760%3B40.66386%2C-111.86464#map=18/40.66520/-111.86552
 It is these kinds of (potentially unsafe) situations that we are really 
looking to prevent, not only for Scout users but for all routing software using 
OSM. (This is in the US not in Canada but the situation could occur anywhere.) 

On Mar 29, 2017, at 11:14 PM, Andrew 

Re: [Talk-it] Attacco di mandata per autopompa

[paolo bubici]

Per me è ok. Aggiorniamo pure la pagina wiki.

Ciao,
Paolo

Il 30/mar/2017 19:12, "girarsi_liste"  ha scritto:

> Il 29/03/2017 22:38, Alberto ha scritto:
> >> Oggi ho messo mano al disegnino, metto in allegato, e come sempre per
> >> chi vuole mando il sorgente SVG per modificarselo e licenza sempre CC-BY
> >
> > Si più o meno una cosa del genere. Ridimensionandolo a 20x20 la scritta
> però non si capisce più (tra l'altro perché ha gli underscore _ ?) e la
> freccetta piccola sparisce del tutto, per cui si potrebbero eliminare. E a
> voler fare i pignoli :) il volantino non è perfettamente perpendicolare al
> tubo.
> > Sentiamo cosa dicono gli altri.
> > Grazie
> > Alberto
> >
>
> La scritta l'ho messa solo per grandi dimensioni (predisposto per 24 x
> 24 Cm), è ovvio che sotto certe dimensioni non si vede, gli underscore
> possono essere fastidiosi, ma chi si mette a legere la scritta sotto
> certe dimensioni, se non ingrandendo zoomando?
>
> Quello che importa è che sia intuitivo il disegnino su OSM, perchè come
> icona deve funzionare, per la scritta, l'ho messa solo per far capire,
> ma forse è di troppo.
>
>
> Altre opinioni?
>
>
>
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Building Footprints in CA

[OSM Volunteer stevea]

Brian M Hamlin maplabs at light42.com writes:
I have been working with 2D building footprints from LA and other counties here 
in Berkeley on a research project, using a PostGIS/GDAL stack and a libosimum 
tool, among others.. 
The project is broadly named  "California OpenData ECN" .. I am committed to an 
open data process. Not much more to say at this moment, but I am reading this 
and want to contribute in some way, when thats possible. 

Excellent!  How fortunate that talk-us has allowed this sort of broad-reach 
connection to occur; it's nice when we resonate on same or similar frequencies. 
 Brian's blurb about his technical stack (PostGIS/GDAL) exactly mimics how 
Kevin (Kenny) recently mentioned how he has approached similar Big Data 
projects:  "pour the shapefiles into PostGIS using ogr2ogr."  Nathan (well, 
maybe NOT Nathan...), that seems a decent initial approach to take to split 
apart the Microsoft data's Bay Area file of 3+million objects, a project to 
which I haven't the volunteer bandwidth to offer right now.  Brian, thank you 
very much for your participation and any continuing future collaboration you 
might be able to offer to help blend/merge these endeavors.  I encourage you to 
remain in listening mode and speak up when it makes sense.

The potential harmony between Brian's building data footprint project and the 
availability (I hesitate to say "early stages of a Microsoft data import," as 
we haven't even the roughest sketch of a project proposal, let alone a formal 
import proposal) bodes well for a future of California (and other places where 
the Microsoft data exist) building footprint data coming into OSM.  Somehow, if 
we keep the good intentions and good communications moving ahead towards good 
consensus, I think we can get there.  But again, it is a gigantic project, and 
it goes without saying once again that it must be done correctly within OSM's 
community (import) guidelines.

Very much in listening mode,

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

Re: [Talk-it] [civici Torino] Offset generale

[Paolo Monegato]

Il 29/03/2017 18:36, Volker Schmidt ha scritto:

Cari amici,

ho paura che questo è solo l'ennesima manifestazione dello stesso 
errore sistematico con tutti gli import fatti finora in 
Veneto.(edifici e landuse).


Beh sarebbe anche normale,... se il dato di partenza è in Roma 40 va da 
se che riproiettandolo con i sistemi che liberamente e legalmente 
possiamo usare risulterà un offset in varie direzioni a seconda dell'area...


ciao

Paolo M


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

Re: [Talk-it] Attacco di mandata per autopompa

[girarsi_liste]

Il 29/03/2017 22:38, Alberto ha scritto:
>> Oggi ho messo mano al disegnino, metto in allegato, e come sempre per
>> chi vuole mando il sorgente SVG per modificarselo e licenza sempre CC-BY
> 
> Si più o meno una cosa del genere. Ridimensionandolo a 20x20 la scritta però 
> non si capisce più (tra l'altro perché ha gli underscore _ ?) e la freccetta 
> piccola sparisce del tutto, per cui si potrebbero eliminare. E a voler fare i 
> pignoli :) il volantino non è perfettamente perpendicolare al tubo.
> Sentiamo cosa dicono gli altri.
> Grazie
> Alberto
> 

La scritta l'ho messa solo per grandi dimensioni (predisposto per 24 x
24 Cm), è ovvio che sotto certe dimensioni non si vede, gli underscore
possono essere fastidiosi, ma chi si mette a legere la scritta sotto
certe dimensioni, se non ingrandendo zoomando?

Quello che importa è che sia intuitivo il disegnino su OSM, perchè come
icona deve funzionare, per la scritta, l'ho messa solo per far capire,
ma forse è di troppo.


Altre opinioni?




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



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

[OSM-talk] Fwd: [HOT] Call for Logos for State of the Map Asia 2017

[maning sambale]

FYI, State of the Map Asia 2017 will happen in Kathmandu Sept-Oct 2017
(dates TBD).  Please help us design the logo.

-- Forwarded message --
From: kshitiz khanal 
Date: Thu, Mar 30, 2017 at 10:23 AM
Subject: [HOT] Call for Logos for State of the Map Asia 2017
To: h...@openstreetmap.org, sotm-a...@openstreetmap.org,
talk...@openstreetmap.org


Dear all,

The State of the Map Asia 2017 working group is pleased to announce a
call for logo designs. We need your help to build a strong
recognisable logo for State of the Map Asia 2017 (SotM Asia)
conference taking place in Kathmandu, Nepal. The conference is
OpenStreetMap’s annual gathering of the community, interested parties
and others in Asia.

We have put together a Design Brief which outlines what we were
looking for in a logo. Entrants could be an individual or team of
people, or even a design company.

All entries will be considered to give copyright ownership to SotM so
that it can be used across different mediums. Entries have to appear
on the wiki page State Of The Map Asia 2017/Logo entries by 23:59 UTC
(before midnight) on 15th of April 2017. The SotM Asia 2017 working
group will decide by vote the logo to go with.

The winning entry will be rewarded with one full weekend ticket to
State of the Map Asia 2017!

For guidelines and other details, please refer to
https://wiki.openstreetmap.org/wiki/Call_for_logo_sotm_asia_2017


Regards,


Kshitiz Khanal

Researcher

Kathmandu Living Labs




___
HOT mailing list
h...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
--

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)]

Attention, ne pas oublier que le RGP c'est du déclaratif. A combiner avec de 
l'orthophoto et/ou les bases d'occupation du sol des collectivités (SIGLR, 
CIGAL et compagnie) quand la licence permet.

Denis

-Message d'origine-
De : Christian Quest [mailto:cqu...@openstreetmap.fr] 
Envoyé : jeudi 30 mars 2017 17:53
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu 
standard

On peut aussi profiter de l'arrivée du RPG (Registre Parcellaire
Graphique) dispo en version 2013 (mais la 2014 arrive en principe d'ici 
quelques jours, la 2015 devrait être dispo en mai et en juillet on aurait la 
2016) pour avoir des géométrie plus précises que CLC et faire d'une pierre deux 
coups.

Le RPG ce sont les parcelles cultivées, ces données sont utilisées pour les 
subventions européennes et mises à jour chaque année.

Marc Sibert avait fait un gros boulot d'intégration avec les données
2012 sur le 91.

Idéalement il faudrait un outil pour faciliter l'intégration... car c'est pas 
trivial sans un peu d'aide.


Les données 2013 sont dispo en LO sur: http://professionnels.ign.fr/rpg


Le 30/03/2017 à 10:38, althio a écrit :
> 2017-03-30 1:24 GMT+02:00 Jérôme Amagat :
>> les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est que ça
>> a été créer pour représenter des champs et pas un corps de ferme.
>> il peut il y avoir des bâtiments au milieu mais c'est en majorité des champs
>> donc le tag landuse=farmland convient donc ensuite :
>>
>> remplacer le tag landuse=farm par landuse=farmland dans toute la sélection
>>
>> ensuite regarder ce qui reste avec le tag landuse=farm pour voir quoi en
>> faire
> On n'est pas pressé ;)
> On peut prendre le temps de comprendre les tags disponibles, de faire
> les distinctions corps[farmyard] / champs[farmland] et d'ajouter les
> bâtiments.
> On peut raffiner la géométrie si c'est du Corine CLC brut.
> ...
>
> -- althio
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Falk Zscheile]

Am 30. März 2017 um 14:14 schrieb Harald Hartmann
:
> Am 30.03.2017 um 09:17 schrieb Uwe Sennewald:
>> Habt ihr schon mal was von LEMnet ( http://www.lemnet.org/de ) gehört ?
>> Die nutzen OSM , müllen es aber mit den Informationen zu den
>> Ladestationen nicht voll.
>
> Hmm, und in wie weit nutzen die OSM? Also die ersten Stickpunkte die ich
> so gemacht habe, lässt den Eindruck erwecken, dass sie NUR einfach eine
> OSM Karte (Tiles) verwenden, von den angezeigten POIs
> (amenity=charging_station, etc.) war kein einziger in der OSM Datenbank.
>
Wenn ich Uwes E-Mail richtig verstanden habe, dann soll es gerade ein
großer Vorteil von LEMnet sein, dass die Ladesäulen außerhalb der
OSM-Datenbank gepflegt werden. Da kann man sicher unterschiedlicher
Ansicht sein ...

Auf der FOSSGIS 2017 gab es einen interessanten Vortrag zu der Frage,
wo Ladesäulen im Idealfall errichtet werden sollten:
https://www.fossgis-konferenz.de/2017/programm/event.php?id=5185

Das löst natürlich leider das aktuelle Ladesäulenproblem nicht im geringsten ...

Gruß Falk

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[Christian Quest]

On peut aussi profiter de l'arrivée du RPG (Registre Parcellaire 
Graphique) dispo en version 2013 (mais la 2014 arrive en principe d'ici 
quelques jours, la 2015 devrait être dispo en mai et en juillet on 
aurait la 2016) pour avoir des géométrie plus précises que CLC et faire 
d'une pierre deux coups.


Le RPG ce sont les parcelles cultivées, ces données sont utilisées pour 
les subventions européennes et mises à jour chaque année.


Marc Sibert avait fait un gros boulot d'intégration avec les données 
2012 sur le 91.


Idéalement il faudrait un outil pour faciliter l'intégration... car 
c'est pas trivial sans un peu d'aide.



Les données 2013 sont dispo en LO sur: http://professionnels.ign.fr/rpg


Le 30/03/2017 à 10:38, althio a écrit :

2017-03-30 1:24 GMT+02:00 Jérôme Amagat :

les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est que ça
a été créer pour représenter des champs et pas un corps de ferme.
il peut il y avoir des bâtiments au milieu mais c'est en majorité des champs
donc le tag landuse=farmland convient donc ensuite :

remplacer le tag landuse=farm par landuse=farmland dans toute la sélection

ensuite regarder ce qui reste avec le tag landuse=farm pour voir quoi en
faire

On n'est pas pressé ;)
On peut prendre le temps de comprendre les tags disponibles, de faire
les distinctions corps[farmyard] / champs[farmland] et d'ajouter les
bâtiments.
On peut raffiner la géométrie si c'est du Corine CLC brut.
...

-- althio

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



--
Christian Quest - OpenStreetMap France


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

Re: [Talk-ca] Telenav mapping turn restrictions

[Martijn van Exel]

Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a 
little slow parsing French).

First off thanks for your additional comments, they are really useful. I 
realize that I should have shared more detail about what we are planning to do 
and will do a better job in the future if new projects arise. We are actually 
working on a Github repository (similar to Mapbox's) where we will share more 
details about mapping projects and where everybody will be able to talk to the 
team about what we do. Of course we will continue to post here as well.

We do have a serious onboarding process for new mappers on our team where more 
experienced mappers guide the newcomers and introduce them to the OSM 
ecosystem. So they are not quite thrown in the deep end, but like everybody 
else they go through a learning process where they make simple edits first. We 
don't ever use live OSM data for pilot or test projects.

I don't feel there's a consensus about the turn restrictions in places where 
they are not marked. There are really good (routing / safety related) reasons 
for this as I pointed out before [1] and in my research I have found many of 
these in the U.S. as well, but until that is cleared up we will not add any 
more. This includes the left turn restrictions Pierre mentioned. To Pierre's 
comments, I don't think that there's really an easier way to map this, turn 
restrictions have been discussed in the community at length and other solutions 
not based on relations just don't scale well to complex situations.

The Bing imagery alignment issue is one that we have not given proper attention 
and I will impress upon the team that they should pay really close attention to 
this and be even more restrained in modifying local mappers' work. I seem to 
remember there is a site / place that lists offset issues with Bing imagery by 
region? Is there a good source to look at for this?

I'm thinking it would be good to hold an online town hall where some of our 
team members and myself can answer any questions and discuss the issues raised? 
If you're interested in this let me know off-list and we can set up a time.

Thanks again for your feedback and willingness to work on this with me and the 
team. We really do want to improve the map for everyone and we will be taking 
this as an opportunity to do significantly better.

Martijn

[1] Look for example at this situation where there is no turn restriction on an 
intersection with a _link road and OSRM does not route over the _link road. 
https://www.openstreetmap.org/directions?engine=osrm_car=40.66610%2C-111.86760%3B40.66386%2C-111.86464#map=18/40.66520/-111.86552
 

 It is these kinds of (potentially unsafe) situations that we are really 
looking to prevent, not only for Scout users but for all routing software using 
OSM. (This is in the US not in Canada but the situation could occur anywhere.) 

> On Mar 29, 2017, at 11:14 PM, Andrew Lester  wrote:
> 
> Hi Martijn,
> 
> Thanks for your comments. Yes, I have commented on relevant changesets, 
> though not every one I've come across. To be honest, there are far too many 
> problematic changesets to start discussions on all of them.
> 
> In using some QA tools to fix other problems, I've come across further 
> instances of what could best be described as "sloppy" edits. For example, 
> adjustments to road alignments to align them with Bing, but obviously with no 
> attempt to properly align the imagery first. Bing is off by 15-20 metres in 
> much of southern Vancouver Island outside of downtown Victoria, and I've seen 
> some roads being moved that much out of place. Here's an example changeset: 
> https://www.openstreetmap.org/changeset/46740353 (viewed with Achavi: 
> https://overpass-api.de/achavi/?changeset=46740353#map=16). I see the source 
> "Geobase roads" has been listed as being used as part of the edits, which 
> actually reflects the correct alignment, but this seems to have been ignored 
> in favour of the poorly-aligned Bing imagery. In addition, I've found a 
> number of edits by Telenav members creating or moving highways such that they 
> cross footways without an intersecting node, which indicates that the JOSM 
> validator isn't being used before uploading the changes.
> 
> In my opinion, based on what I'm seeing, the Telenav members don't have 
> enough experience with the OSM ecosystem, tagging/mapping conventions, or 
> editing tools to be making such widespread and prolific changes. I would 
> strongly recommend that these members focus on mapping a local area that they 
> can visit in person in order to gain experience with all aspects of actual 
> on-the-ground mapping, and then later begin expanding to the rest of the 
> country. Right now it seems like they're being thrown into the deep end with 
> the hope that they'll just 

[OSM-talk-fr] Relation type=route étrange

[Charles MILLET]

Bonjour,

J'ai remarqué des relations d'itinéraire cyclable qui me paraissent 
inadapté aux modèles acceptés ; exemples :


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

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

On dirait que l'objectif est plus d'avoir un rendu des pistes cyclables 
d'une agglomération ou d'une grande ville mise en valeur dans des outils 
tels que waymarkedtrails.org


J'ai contacté à deux reprise la personne qui les a créée pour lui 
proposer d'autres moyens d'afficher les pistes cyclables d'une villes ou 
d'une agglo et en expliquant qu'à ma connaissance les relations de type 
route ne sont pas adaptées à ce type d'objectif... Je n'ai pas eu de 
réponse :\


J'ai deux questions :

– Est-ce que vous pensez qu'effectivement il ne s'agit pas d'itinéraires 
et que les relations d'OSM n'ont pas (encore) vocation à contenir ce 
type d'information ?


– Qu'est-ce qu'on fait dans cette situation ? Est-ce qu'on supprime la 
relation ?


À bientôt.


--
Charles MILLET
charlesmil...@free.fr


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

[OSM-talk-fr] Nomino en panne ?

[Christian Rogel]

Bonjour, 

Quand je cherche un toponyme avec Nomino : https://nomino.openstreetmap.fr/ 
 et que je clique sur un élément de ce qui 
est retourné, j’obtiens "invalid object ».

Une solution en vue ?


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

Re: [Talk-it] Il nuovo portale cartografico nazionale è online #opendatafail

[Maurizio Napolitano]

2017-03-30 16:50 GMT+02:00 Cascafico Giovanni :
> in ogni caso la cosa più utile, i numeri civici, appaiono come:
>
> - Servizi - Numeri civici - Aggiornamento 2012
> - Dataset - Numeri civici - Aggiornamento 2012
>
> ma entrambi i link non fanno che fornire lo stesso indirizzo del WMS. ho
> provato a caricarlo come sfonfo in JOSM, ma francamente avere un raster con
> dei pallini azzurri e null'altro non aiuta molto.

Esiste anche il WFS, ma essendo dati del 2012 e già pieni di errori e
con una licenza non compatibile con OSM non perderei troppo tempo.

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

Re: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií nefunguje

[Zdeněk Pražák]

no může být, přesto bych ale byl pro ignoraci fotek s tagem nečitelné
-- Původní e-mail --
Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 3. 2017 13:44:15
Předmět: Re: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií
nefunguje
"Ahoj, driv to tak bylo ale v praxi mi prislo vhodnejsi vedet, jake
fotky v okoli jsou i kdyz to nejsou ty spravne. Jednak pro prehled a i
kvuli tomu, ze tagovani muze byt chybne, dost casto takto nejake tagy
u fotek opravuju. Pripadne je tam situace kde na miste rozcestniku
existuje fotka konce znacky = rozcestnik tam tedy asi neni, ale je
dobre tam tu fotku mit (nez to nekdo na miste proveri a priapdne uzel
z OSM smaze).

Co ty na to?


Dne 30. března 2017 13:02 Zdeněk Pražák  napsal(a):
> díky za opravu - ale mám ještě dotaz - proč jsou na stránce
> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cor uvedeny fotky s tagy nečitelné,
> cyklo, mapa atd
> Tyto by snad měly být ignorovány
>
> Pražák
>
> Dne 30. března 2017 9:57 Tom Ka  napsal(a):
>
>> Zrusil jsem v OSM i fotce 'a' na konci ref, posun a dalsi jsi asi
>> udelal ty, kazdopadne vyreseno.
>>
>> Mej se.
>>
>> Dne 29. března 2017 20:48 Tom Ka  napsal(a):
>> > ahoj, zitra na to mrknu bliz, ale do ref to pismenko nepatri. ozvu se
>> > ti.
>> >
>> > bye
>> >
>> > On Mar 29, 2017 18:27, "Zdeněk Pražák"  wrote:
>> >>
>> >> mám problém s rozcestníkem ref SY178a nalézajícím se u autobusové
>> >> zastávky
>> >> v obci Korouhev
>> >> Při kontrole spárovanosti se fotka tohoto rozcestníku s ID 11713
>> >> spáruje s
>> >> rozcestníkem SY178 nalézajícím se asi 18 km mimo.
>> >> opravil jsem již dříve ref rozcestníku z SY178 na SY178a
>> >> oprava z fronty rozcestníků čekajících na přesun zmizela ale ref se
>> >> neopravil a zůstal na původní hodnote SY178
>> >>
>> >> jak toto opravit
>> >>
>> >> Pražák
>> >>
>> >> Dne 29. března 2017 16:02 Tom Ka  napsal(a):
>> >>>
>> >>> Provedl jsem v tomto nejake zmeny chovani spusteni analyzy
>> >>> rozcestniku. Ted by to melo byt robustnejsi bez vetsi ztraty
>> >>> pouzitelnost a flexibility.
>> >>>
>> >>> Bye
>> >>>
>> >>> Dne 26. března 2017 20:19 Tom Ka  napsal
(a):
>> >>> > Ahoj, to je znamy problem kdy nekdo pusti analyzu a pak zavre
>> >>> > zalozku/stranku. Mam nejakou predstavu, jak to prekopat ale zatim
>> >>> > jsem
>> >>> > se k
>> >>> > tomu nedostal. Pristi analyza to opravi, takze to asi neni uplne
>> >>> > kriticke.
>> >>> >
>> >>> > Bye
>> >>> >
>> >>> >
>> >>> > On Mar 26, 2017 19:59, "Zdeněk Pražák"  wrote:
>> >>> >>
>> >>> >> tak beru zpět, po chvíli se při novém pokusu objevilo 18610
>> >>> >> rozcestníků
>> >>> >>
>> >>> >>
>> >>> >> -- Původní zpráva --
>> >>> >> Od: Zdeněk Pražák 
>> >>> >> Komu: talk-cz@openstreetmap.org
>> >>> >> Datum: 26. 3. 2017 19:54:45
>> >>> >> Předmět: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií
>> >>> >> nefunguje
>> >>> >>
>> >>> >>
>> >>> >> kontrola spárovanosti rozcestníků a fotografií na
>> >>> >> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?all nefunguje. Zobrazí se
>> >>> >> pouze
>> >>> >> 57
>> >>> >> rozcestníků
>> >>> >> Pražák
>> >>> >> ___
>> >>> >> 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
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
>

___
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-it] Il nuovo portale cartografico nazionale è online #opendatafail

[Cascafico Giovanni]

in ogni caso la cosa più utile, i numeri civici, appaiono come:

- Servizi - Numeri civici - Aggiornamento 2012
- Dataset - Numeri civici - Aggiornamento 2012

ma entrambi i link non fanno che fornire lo stesso indirizzo del WMS. ho
provato a caricarlo come sfonfo in JOSM, ma francamente avere un raster con
dei pallini azzurri e null'altro non aiuta molto.



Il giorno 30 marzo 2017 14:22, Maurizio Napolitano  ha
scritto:

> 2017-03-29 19:40 GMT+02:00 Cascafico Giovanni :
> > I metadati della pagina "Numeri Civici - Aggiornamento 2012" [1]
>
> Questo dataset c'era anche nel precedente portale e con licenza cc-by-sa.
>
> > [...]
> >
> > Non vedo la clausola "NC". Forse non è il dataset completo?
>
> non hanno dimenticato li
> Hanno sbagliato a scrivere la gestione delle licenze fra note legali,
> faq e metadati del singolo dataset.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] OSM som underlag för att producera CC0/CC BY-material i rasterform?

[Karl Wettin]

> On 30 Mar 2017, at 15:36, Bernt Rane  wrote:

Hej Bernt,
 
> ODbL är ju till sin natur lite mer restriktiv då den kräver samma licensform 
> för bearbetningar av data om vi förstått rätt. Dvs mer lik CC BY-SA.

Det stämmer, ODbL är mycket lik CC-BY-SA.

> Åtminstone om man släpper sitt aggregerade data vidare i vektorform.
> Frågan: om man skapar a) kartbilder eller b) karttjänster (i form av 
> rastertjänster av typen WMS eller slippy map/xyz-maps) och det ingår OSM som 
> del i underlagen är det enligt villkoren att släppa dessa kartbilder resp 
> rasterkarttjänster för vidareutnyttjande som CC BY / CC0?

Min tolkning av ODbL är att alla derivat måste bli ODbL, men alla verkar inte 
hålla med om det.

Sedan vet jag inte om det är så att du frågar huruvida ni får släppa era egna 
data som CC0 när ni redan skänkt dem som ODbL till OSM? Det går naturligtvis 
utmärkt att licensiera sina egna data på flera sätt, exempelvis att man lägger 
ut den som CC0 på ett ställe och samtidigt donerar den som ODbL till OSM. Men 
så fort du lyfter data från OSMs databas så måste du lämna källhänvisning.

Här finns för övrigt en påbörjad Sverige-karta som helt och hållet bygger på 
CC0-licensierad data: >

> Antar att frågan har ställts förr och vi har ju tillgång till licensen som vi 
> nu gräver i, men jag är intresserad av hur en diskussion kring detta har gått 
> förut och om det finns något mer skrivet kring detta (annat än i själva 
> licensen ODbL då).


OSM bytte från CC-BY-SA till ODbL den 12 september 2012. Det föranleddes av en 
stor diskussion där man förenklat vägde mellan CC0 och just ODbL. Om man 
förenklar den förenklingen så löd argumentet ungefär att detta är data som till 
absolut största del skapas på fritid av volontärer och det är inte mer än rätt 
att de skall få creds för sitt jobb, speciellt om man skall locka till sig fler 
volontärer. 

Personligen kan jag ha förståelse för att argumentet är lockande, men sluter 
mig till lägret som anser att den större samhällsnyttan, både lokalt och 
globalt, på kort och lång sikt, kommer när man inte sätter några som helst 
restriktioner på hur datamängderna får användas. Att om måttet på framgång för 
öppna data är hur mycket de används så motverkar man sitt eget mål när man 
sätter den minsta restriktion. Det står mer om det argumentet här: 
>.



kalle___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-fr] Arrêts de bus sans nom dans MAPS.ME

[Shohreh]

J'utilise aussi Maps.me depuis quelques années. Simple et suffisante pour mes
besoins. Manque juste quelques trucs comme la possibilité de prendre une
photo pour illustrer un POI.

Les modifications apportées aux POIs importés via le KML sont envoyées sur
les serveurs de Maps.me : il n'est donc pas possible en local de vérifier la
qualité des modifs comme le respect de la casse.

https://support.maps.me/hc/en-us/sections/201941155-Map-editor



--
View this message in context: 
http://gis.19327.n8.nabble.com/Arrets-de-bus-sans-nom-dans-MAPS-ME-tp5893738p5894434.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-GB] Layby restricted to abnormal loads

[ael]

On Thu, Mar 30, 2017 at 08:12:36AM +0100, Adam Snape wrote:
> As bicycles are vehicles (and not all other vehicles are motorised) that
> can be tagged as vehicle=no hgv=yes. Given that the exclusion likely
> includes more than just vehicles (eg. horses) , access=no foot=yes hgv=yes
> is maybe a better option.
> 
That sounds much better, although maybe there is a need for a new 
restriction tag.

ael


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

Re: [Talk-GB] Layby restricted to abnormal loads

[ael]

On Thu, Mar 30, 2017 at 07:00:15AM +0100, David Woolley wrote:
> On 29/03/17 21:32, ael wrote:
> > and, for good measure, hgv=permissive.
> 
> Permissive sounds wrong to me.  Permissive basically reflects the rights of
> the land owner, and for users is the same as yes.

Well, yes, but looking down the list of values offered on the presets in
josm, that seemed the nearest. After all the landowner is giving
permission if there is an abnormal load.

We seem to be missing a restriction value for this sort of thing.

ael


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

Re: [Talk-se] OSM som underlag för att producera CC0/CC BY-material i rasterform?

[Ture Pålsson]

On 2017-03-30 15:36, Bernt Rane wrote:

[...]


Frågan: om man skapar a) kartbilder eller b) karttjänster (i form av 
rastertjänster av typen WMS eller slippy map/xyz-maps) och det ingår 
OSM som del i underlagen är det enligt villkoren att släppa dessa 
kartbilder resp rasterkarttjänster för vidareutnyttjande som CC BY / CC0?


Rasterbilder och -tjänster *tror* jag räknas som "produced work", och då 
gäller lite friare villkor än om man gör en "derivative database", fast 
jag kommer inte ihåg exakt vad som gäller.


Antar att frågan har ställts förr och vi har ju tillgång till licensen 
som vi nu gräver i, men jag är intresserad av hur en diskussion kring 
detta har gått förut och om det finns något mer skrivet kring detta 
(annat än i själva licensen ODbL då).


Det finns en uppsättning "community guidelines", som är tänkta som någon 
slags tolkningsguide till ODBL som den tillämpas inom OSM-projektet, 
här: http://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines .


T.ex. använder ju Stockholms Lokaltrafik numera OSM som bakgrundskarta 
på sin website, och såvitt jag vet har ingen skrikit i högan sky om att 
de kombinerar OSM med proprietära data om hållplatser och annat. De är 
(väl?) dessutom också en myndighet, så det kan ju vara läge att prata 
med deras lagvrängare, om ni nu inte redan gjort det. :)



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

[Talk-at] Verwendung von Multipolygonen

[jdz5274]

Bei der (wieder einmal) intensiven Beschäftigung mit Multipolygonen sind mir - 
abseits der Geometrie - einige fragwürdige Verwendungen aufgefallen. Dazu ein 
paar hoffentlich hilfreiche Fragen und Beispiele (aus Österreich).

Grundsätzlich: eine Multipolygon-Relation [1] (MPR) statt eines Polygons 
(geschlossene Linie) braucht es 
a) wenn eine Fläche ein Loch hat
b) wenn die Grenze der Fläche aus mehr als einer Linie besteht (im Weiteren 
nicht von Bedeutung)

Tags an der Relation beziehen sich auf diese, Tags an den Innen/Außenlinien 
gelten unabhängig davon für diese Linien und können zusätzliche Flächen 
begründen [2].


1. Macht jedes Objekt für sich allein betrachtet (aus der Datenbank abgefragt) 
Sinn? [2]

leisure=park umfasst den ganzen Park inklusive Vegetation [3] und 
Einrichtungen. Wiese, Wald, Wasserflächen, Sportflächen (sofern allgemein 
zugänglich), Spielplätze, Toiletten, ev. auch Parkcafe etc. gehören dazu -> 
diese daher NICHT ausschneiden! (sonst besteht das Park-Objekt hauptsächlich 
aus Löchern). 

Objekte die sich gegenseitig ausschließen (See im Wald, Insel im Fluss, 
Fabrikgelände im Wohngebiet) -> MPR, wenn eines das andere umschließt.

2. Welches Flächen-Tag wohin - an das MPR, den Umriss oder ein separates 
Polygon (-> Wiki!)?

amenity=school bezeichnet das Schulgelände [4], inkl. Gebäuden, Sportplatz etc. 
-> i.A. separates Polygon. Besteht die Schule nur aus einem Gebäude, und dieses 
hat einen Innenhof (Gebäude ist MPR): amenity am outer Ring (Umriss) -> Hof ist 
inkludiert, amenity an der Relation -> Hof ist nicht Teil des Schulgeländes.

3. Handelt es sich wirklich um die Fläche eines Objekts, oder die Gruppierung 
mehrerer Objekte?

Flächen sollten nicht in einer MPR zusammengefasst werden, weil sie zufällig 
die gleichen Tags haben [5]: Mapper A erstellt eine MPR mit 10 Waldstücken, 
Mapper B eine mit 10 Wiesen, Mapper C verschränkt die beiden Relationen mit 
inner/outer-Beziehungen (das gibt's wirklich!). Besser: individuell als 
Polygone mappen, dann MPRs bilden wo nötig.

Auf einem Gelände (z.B. Bauernhof, Wohnblock, Spital) stehen mehrere Gebäude. 
Diese werden als eine MPR mit outer-Ringen dargestellt (s.a. Punkt 1). Die Tags 
an der MPR gelten für alle Gebäude, somit müssen individuelle Tags (Adresse, 
Gebäudetyp,...) an die outer-Ringe, das MPR dient nur noch zur Gruppierung. 
Viel klarer: jedes Gebäude separat modellieren und auf eine gemeinsame Fläche 
(amenity, landuse) stellen (allenfalls noch mit place=*, name=* o.ä.).

Die Flächen einer Streusiedlung werden in einer MPR (landuse=*, name=*) 
zusammengefasst. Nicht nur, dass in Mapnik jede Fläche den MPR-Namen trägt 
(vielleicht ändert sich das ja mal), müssen unterschiedliche landuses auf die 
outer-Ringe, wo sie im Widerspruch zur MPR stehen. Besser: jede Fläche separat 
mappen und anders zusammenfassen (Adressen; gemeinsames is_in=*; Polygon mit 
place=*, name=*).


Übrigens: formal stehen die MPRs in Österreich gerade recht gut da, bis auf die 
in OSMI [6] gezeigten Probleme und Aufräumarbeiten nach der "old-style 
multipolygon"-Beseitigung [7]. Davon abgesehen sind die größten Themen aus 
meiner Sicht das Aufspalten von Monster-Relationen, Überlappungen 
(unvollständige/fehlende MPRs) und die Verfeinerung des Taggings (s.o.).
 

Hoffentlich ist etwas für Euch dabei, bin schon gespannt auf Eure Kommentare,

LG
Wolfgang


[1] https://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon
[2] https://github.com/osmlab/fixing-polygons-in-osm/issues/26 (3. Eintrag von 
Jochen Topf)
[3] https://wiki.openstreetmap.org/wiki/DE:Tag:leisure%3Dpark
[4] https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool
[5] Dazu gab es kürzlich einen Kommentar von Frederik Ramm, den ich gerade 
nicht finde.
[6] 
http://tools.geofabrik.de/osmi/?view=areas=14.36719=47.69424=8=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,role_should_be_inner,role_should_be_outer,inner_with_same_tags
[7] http://area.jochentopf.com/old-style-josm.html




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

Re: [talk-ph] Missing Road

[Eugene Alvin Villar]

On Thu, Mar 30, 2017 at 3:21 PM, Jim Morgan  wrote:

> Also, you used to be able to right click on the map to load the image.
> Seems like OSM has hijacked the right click menu.
>

This was announced here: http://www.openstreetmap.org/user/mcld/diary/40503
And debated extensively starting here:
https://lists.openstreetmap.org/pipermail/dev/2017-February/029713.html

You can still access the normal browser context menu by doing
Shift+Right-click in Firefox and Chrome.

It turns out that Leaflet, the JS map library that powers the map, will be
moving towards displaying the map tiles not as individual HTML images but
as a seamless canvas so even if the new OSM right-click menu wasn't
implemented, you won't be able to access the tile by right-click anyway.
But you can still use your browser dev tools to access the map tile.
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-se] OSM som underlag för att producera CC0/CC BY-material i rasterform?

[Bernt Rane]

Hej, har följt listan ett tag och nu har vi en aktuell fråga.

Jag jobbar på en statlig myndighet, Havs- och vattenmyndigheten, och OSM är en 
intressant datamängd för oss.
Bland annat efter påtryckning från OSM mfl att bli tydligare i villkor på våra 
myndighetsdata så har vi anammat den tidigare e-delegationens rekommendationer 
att släppa vår information så fri som  möjlighet genom att använda CC0 resp CC 
BY som villkor.

ODbL är ju till sin natur lite mer restriktiv då den kräver samma licensform 
för bearbetningar av data om vi förstått rätt. Dvs mer lik CC BY-SA. Åtminstone 
om man släpper sitt aggregerade data vidare i vektorform.
Frågan: om man skapar a) kartbilder eller b) karttjänster (i form av 
rastertjänster av typen WMS eller slippy map/xyz-maps) och det ingår OSM som 
del i underlagen är det enligt villkoren att släppa dessa kartbilder resp 
rasterkarttjänster för vidareutnyttjande som CC BY / CC0?

Antar att frågan har ställts förr och vi har ju tillgång till licensen som vi 
nu gräver i, men jag är intresserad av hur en diskussion kring detta har gått 
förut och om det finns något mer skrivet kring detta (annat än i själva 
licensen ODbL då).

Med vänlig hälsning
Bernt Rane
Gis-strateg, Havs- och vattenmyndigheten
010-698 62 81
www.havochvatten.se


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

Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Harald Hartmann]

Ja, nach meinem Blog "maxspeed .. eine Perle des Wikis" [1], bin ich
ganz klar sofort dafür, da mal ein bisschen aufzuräumen :)
Trotzdem sollte denke ich mal weiterhin die Möglichkeit geprüft werden,
in diversen QA-Tools die Prüfung source:maxspeed=:
ungleich maxspeed= unterzubringen.

[1] http://www.openstreetmap.org/user/Harald%20Hartmann/diary/40119#comments

PS: Dann wird es eventuell auch mal was, um den anderen Haufen Kleinvieh
Mist aufzuräumen:

...


















...

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

Re: [OSM-talk] multipolygon source tags preferred method

[Paul Johnson]

On Mon, Mar 27, 2017 at 9:06 AM, nwastra  wrote:

> Putting the sources on the objects has been deprecated for a while. The
> source should be put on the changeset only. If you are doing edits that
> involve several different sources, it is best to split the changes up
> into different changesets. Of course this is not always possible, then
> you can also put several sources in the changeset source tag.
>
> Adding the source to the objects was deprecated, too fined-grained
> source tagging simply doesn't make much sense. We can not track every
> source for every node, way, or relation or the parts of them for every
> tiny change that somebody does. In the end most data will have multiple
> sources and figuring out what came from what can only be done going
> through the changeset tags, not by looking at the tags on the data
> itself.
>
> Jochen
> --
> Jochen Topf
>
>
I have been known to use the name:source=* and maxspeed:source=* keys as
Oklahoma signage is generously described as "creative", causing people to
sometimes incorrectly clear name=* or replace it.  This tends to occur most
commonly on highways renamed within roughly the last 5-10 years, and on
dual carriageways where one carriageway has a different name than the
opposite carriageway.  And posting countywide speed limits exactly one time
at the county boundary on a sign apparently written in 3 point Flyspeck
font, hidden in a bush

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

Re: [Talk-it] Il nuovo portale cartografico nazionale è online #opendatafail

[Maurizio Napolitano]

2017-03-29 19:40 GMT+02:00 Cascafico Giovanni :
> I metadati della pagina "Numeri Civici - Aggiornamento 2012" [1]

Questo dataset c'era anche nel precedente portale e con licenza cc-by-sa.

> [...]
>
> Non vedo la clausola "NC". Forse non è il dataset completo?

non hanno dimenticato li
Hanno sbagliato a scrivere la gestione delle licenze fra note legali,
faq e metadati del singolo dataset.

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

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Harald Hartmann]

bzw. noch besser: http://www.openstreetmap.org/node/4214500413 ist laut
http://www.lemnet.org/map/ auf der anderen Straßeseite von "An der
Quelle"...

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

[Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Martin Koppenhoefer]

Es gibt mehrere Standards und ein paar weitere Alternativen, um 30er Zonen
zu taggen.

Dazu hier im wiki:
https://wiki.openstreetmap.org/wiki/Key:source:maxspeed

Aktuelle Zahlen von heute:
maxspeed=30 and zone:maxspeed=DE:30 - 32952 uses
maxspeed=30 and source:maxspeed=DE:zone30 - 32018 uses
maxspeed=30 and source:maxspeed=DE:zone:30 - 21832 uses

(die Nutzungen beziehen sich nicht auf die Kombination mit maxspeed=30
sondern nur auf den 2. Tag, sollte aber keine große Abweichung sein).

Wie wärs, wenn wir zumindest

source:maxspeed=DE:zone30 und
source:maxspeed=DE:zone:30

vereinheitlichen würden, per Einigung auf eine Variante und mechanisches
Umtaggen?

Die weiteren dokumentierten Varianten sind
source:maxspeed=DE:zone und
source:maxspeed=zone

mit 5k und 1,8k Nutzung.


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

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Harald Hartmann]

Am 30.03.2017 um 09:17 schrieb Uwe Sennewald:
> Habt ihr schon mal was von LEMnet ( http://www.lemnet.org/de ) gehört ?
> Die nutzen OSM , müllen es aber mit den Informationen zu den 
> Ladestationen nicht voll.

Hmm, und in wie weit nutzen die OSM? Also die ersten Stickpunkte die ich
so gemacht habe, lässt den Eindruck erwecken, dass sie NUR einfach eine
OSM Karte (Tiles) verwenden, von den angezeigten POIs
(amenity=charging_station, etc.) war kein einziger in der OSM Datenbank.

Hast du ein paar Beispiele, wo du sicher nachweisen kannst, dass auch
Ladesäulen, die in OSM erfasst wurden, so eins zu eins auch auf lemnet
angezeigt werden?

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

Re: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií nefunguje

[Tom Ka]

Ahoj, driv to tak bylo ale v praxi mi prislo vhodnejsi vedet, jake
fotky v okoli jsou i kdyz to nejsou ty spravne. Jednak pro prehled a i
kvuli tomu, ze tagovani muze byt chybne, dost casto takto nejake tagy
u fotek opravuju. Pripadne je tam situace kde na miste rozcestniku
existuje fotka konce znacky = rozcestnik tam tedy asi neni, ale je
dobre tam tu fotku mit (nez to nekdo na miste proveri a priapdne uzel
z OSM smaze).

Co ty na to?


Dne 30. března 2017 13:02 Zdeněk Pražák  napsal(a):
> díky za opravu - ale mám ještě dotaz - proč jsou na stránce
> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cor uvedeny fotky s tagy nečitelné,
> cyklo, mapa atd
> Tyto by snad měly být ignorovány
>
> Pražák
>
> Dne 30. března 2017 9:57 Tom Ka  napsal(a):
>
>> Zrusil jsem v OSM i fotce 'a' na konci ref, posun a dalsi jsi asi
>> udelal ty, kazdopadne vyreseno.
>>
>> Mej se.
>>
>> Dne 29. března 2017 20:48 Tom Ka  napsal(a):
>> > ahoj, zitra na to mrknu bliz, ale do ref to pismenko nepatri. ozvu se
>> > ti.
>> >
>> > bye
>> >
>> > On Mar 29, 2017 18:27, "Zdeněk Pražák"  wrote:
>> >>
>> >> mám problém s rozcestníkem ref SY178a nalézajícím se u autobusové
>> >> zastávky
>> >> v obci Korouhev
>> >> Při kontrole spárovanosti se fotka tohoto rozcestníku s ID 11713
>> >> spáruje s
>> >> rozcestníkem SY178 nalézajícím se asi 18 km mimo.
>> >> opravil jsem již dříve ref rozcestníku z SY178 na SY178a
>> >> oprava z fronty rozcestníků čekajících na přesun zmizela ale ref se
>> >> neopravil a zůstal na původní hodnote SY178
>> >>
>> >> jak toto opravit
>> >>
>> >> Pražák
>> >>
>> >> Dne 29. března 2017 16:02 Tom Ka  napsal(a):
>> >>>
>> >>> Provedl jsem v tomto nejake zmeny chovani spusteni analyzy
>> >>> rozcestniku. Ted by to melo byt robustnejsi bez vetsi ztraty
>> >>> pouzitelnost a flexibility.
>> >>>
>> >>> Bye
>> >>>
>> >>> Dne 26. března 2017 20:19 Tom Ka  napsal(a):
>> >>> > Ahoj, to je znamy problem kdy nekdo pusti analyzu a pak zavre
>> >>> > zalozku/stranku. Mam nejakou predstavu, jak to prekopat ale zatim
>> >>> > jsem
>> >>> > se k
>> >>> > tomu nedostal. Pristi analyza to opravi, takze to asi neni uplne
>> >>> > kriticke.
>> >>> >
>> >>> > Bye
>> >>> >
>> >>> >
>> >>> > On Mar 26, 2017 19:59, "Zdeněk Pražák"  wrote:
>> >>> >>
>> >>> >> tak beru zpět, po chvíli se při novém pokusu objevilo 18610
>> >>> >> rozcestníků
>> >>> >>
>> >>> >>
>> >>> >> -- Původní zpráva --
>> >>> >> Od: Zdeněk Pražák 
>> >>> >> Komu: talk-cz@openstreetmap.org
>> >>> >> Datum: 26. 3. 2017 19:54:45
>> >>> >> Předmět: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií
>> >>> >> nefunguje
>> >>> >>
>> >>> >>
>> >>> >> kontrola spárovanosti rozcestníků a fotografií na
>> >>> >> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?all nefunguje. Zobrazí se
>> >>> >> pouze
>> >>> >> 57
>> >>> >> rozcestníků
>> >>> >> Pražák
>> >>> >> ___
>> >>> >> 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
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
>

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

Re: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií nefunguje

[Zdeněk Pražák]

díky za opravu - ale mám ještě dotaz - proč jsou na stránce
http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cor uvedeny fotky s tagy nečitelné,
cyklo, mapa atd
Tyto by snad měly být ignorovány

Pražák

Dne 30. března 2017 9:57 Tom Ka  napsal(a):

> Zrusil jsem v OSM i fotce 'a' na konci ref, posun a dalsi jsi asi
> udelal ty, kazdopadne vyreseno.
>
> Mej se.
>
> Dne 29. března 2017 20:48 Tom Ka  napsal(a):
> > ahoj, zitra na to mrknu bliz, ale do ref to pismenko nepatri. ozvu se ti.
> >
> > bye
> >
> > On Mar 29, 2017 18:27, "Zdeněk Pražák"  wrote:
> >>
> >> mám problém s rozcestníkem ref SY178a nalézajícím se u autobusové
> zastávky
> >> v obci Korouhev
> >> Při kontrole spárovanosti se fotka tohoto rozcestníku s ID 11713
> spáruje s
> >> rozcestníkem SY178 nalézajícím se asi 18 km mimo.
> >> opravil jsem již dříve ref rozcestníku z SY178 na SY178a
> >> oprava z fronty rozcestníků čekajících na přesun zmizela ale ref se
> >> neopravil a zůstal na původní hodnote SY178
> >>
> >> jak toto opravit
> >>
> >> Pražák
> >>
> >> Dne 29. března 2017 16:02 Tom Ka  napsal(a):
> >>>
> >>> Provedl jsem v tomto nejake zmeny chovani spusteni analyzy
> >>> rozcestniku. Ted by to melo byt robustnejsi bez vetsi ztraty
> >>> pouzitelnost a flexibility.
> >>>
> >>> Bye
> >>>
> >>> Dne 26. března 2017 20:19 Tom Ka  napsal(a):
> >>> > Ahoj, to je znamy problem kdy nekdo pusti analyzu a pak zavre
> >>> > zalozku/stranku. Mam nejakou predstavu, jak to prekopat ale zatim
> jsem
> >>> > se k
> >>> > tomu nedostal. Pristi analyza to opravi, takze to asi neni uplne
> >>> > kriticke.
> >>> >
> >>> > Bye
> >>> >
> >>> >
> >>> > On Mar 26, 2017 19:59, "Zdeněk Pražák"  wrote:
> >>> >>
> >>> >> tak beru zpět, po chvíli se při novém pokusu objevilo 18610
> >>> >> rozcestníků
> >>> >>
> >>> >>
> >>> >> -- Původní zpráva --
> >>> >> Od: Zdeněk Pražák 
> >>> >> Komu: talk-cz@openstreetmap.org
> >>> >> Datum: 26. 3. 2017 19:54:45
> >>> >> Předmět: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií
> >>> >> nefunguje
> >>> >>
> >>> >>
> >>> >> kontrola spárovanosti rozcestníků a fotografií na
> >>> >> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?all nefunguje. Zobrazí se
> pouze
> >>> >> 57
> >>> >> rozcestníků
> >>> >> Pražák
> >>> >> ___
> >>> >> 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
> >>
> >>
> >>
> >> ___
> >> 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] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

2017-03-30 1:24 GMT+02:00 Jérôme Amagat :
> les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est que ça
> a été créer pour représenter des champs et pas un corps de ferme.
> il peut il y avoir des bâtiments au milieu mais c'est en majorité des champs
> donc le tag landuse=farmland convient donc ensuite :
>
> remplacer le tag landuse=farm par landuse=farmland dans toute la sélection
>
> ensuite regarder ce qui reste avec le tag landuse=farm pour voir quoi en
> faire

On n'est pas pressé ;)
On peut prendre le temps de comprendre les tags disponibles, de faire
les distinctions corps[farmyard] / champs[farmland] et d'ajouter les
bâtiments.
On peut raffiner la géométrie si c'est du Corine CLC brut.
...

-- althio

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

> JOSM est votre ami : j'ai regardé par chez moi et je suppose qu'ailleurs
> c'est pareil : il n'y avait pas de découpe entre la partie corps de ferme et
> la partie champ (logique : on ne distinguait pas les deux). Donc il va
> falloir découper.

Les tags étaient là mais ils étaient mal compris, d'où des choses à reprendre.
Une bonne image vaut mieux que mille mots pour l'usage basique en landuse
http://wiki.openstreetmap.org/wiki/File:Landuse%3Dfarmyard.jpg

Mais on peut bien sûr aller plus loin en landuse "agricole" :
landuse=farmland
landuse=meadow
landuse=orchard
landuse=vineyard
landuse=* ...


> je ne vois pas trop l'intérêt soit dit en passant : les bâtiments
> d'une zone agricole sont des bâtiments agricoles. En le disant explicitement
> on ne dit pas grand chose de plus.

L'usage de "landuse" et de "building" n'est pas le même (c'est la même
histoire avec les écoles, ...).
Tant qu'on parle de "landuse" :
landuse=farmyard est pour l'espace qui correspond au corps de ferme,
il contient des bâtiments et des zones de travail mais n'est pas un
bâtiment.
landuse=farmland est pour les champs / terres / espaces cultivés...

Quand on passe aux bâtiments :
http://wiki.openstreetmap.org/wiki/Tag:building%3Dfarm
building=farm
building=barn
building=stable
building=sty
building=cowshed
building=farm_auxiliary

-- althio

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

Re: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií nefunguje

[Tom Ka]

Zrusil jsem v OSM i fotce 'a' na konci ref, posun a dalsi jsi asi
udelal ty, kazdopadne vyreseno.

Mej se.

Dne 29. března 2017 20:48 Tom Ka  napsal(a):
> ahoj, zitra na to mrknu bliz, ale do ref to pismenko nepatri. ozvu se ti.
>
> bye
>
> On Mar 29, 2017 18:27, "Zdeněk Pražák"  wrote:
>>
>> mám problém s rozcestníkem ref SY178a nalézajícím se u autobusové zastávky
>> v obci Korouhev
>> Při kontrole spárovanosti se fotka tohoto rozcestníku s ID 11713 spáruje s
>> rozcestníkem SY178 nalézajícím se asi 18 km mimo.
>> opravil jsem již dříve ref rozcestníku z SY178 na SY178a
>> oprava z fronty rozcestníků čekajících na přesun zmizela ale ref se
>> neopravil a zůstal na původní hodnote SY178
>>
>> jak toto opravit
>>
>> Pražák
>>
>> Dne 29. března 2017 16:02 Tom Ka  napsal(a):
>>>
>>> Provedl jsem v tomto nejake zmeny chovani spusteni analyzy
>>> rozcestniku. Ted by to melo byt robustnejsi bez vetsi ztraty
>>> pouzitelnost a flexibility.
>>>
>>> Bye
>>>
>>> Dne 26. března 2017 20:19 Tom Ka  napsal(a):
>>> > Ahoj, to je znamy problem kdy nekdo pusti analyzu a pak zavre
>>> > zalozku/stranku. Mam nejakou predstavu, jak to prekopat ale zatim jsem
>>> > se k
>>> > tomu nedostal. Pristi analyza to opravi, takze to asi neni uplne
>>> > kriticke.
>>> >
>>> > Bye
>>> >
>>> >
>>> > On Mar 26, 2017 19:59, "Zdeněk Pražák"  wrote:
>>> >>
>>> >> tak beru zpět, po chvíli se při novém pokusu objevilo 18610
>>> >> rozcestníků
>>> >>
>>> >>
>>> >> -- Původní zpráva --
>>> >> Od: Zdeněk Pražák 
>>> >> Komu: talk-cz@openstreetmap.org
>>> >> Datum: 26. 3. 2017 19:54:45
>>> >> Předmět: [Talk-cz] kontrola spárovanosti rozcestníků a fotografií
>>> >> nefunguje
>>> >>
>>> >>
>>> >> kontrola spárovanosti rozcestníků a fotografií na
>>> >> http://osm.fit.vutbr.cz/OsmHiCheck/gp/?all nefunguje. Zobrazí se pouze
>>> >> 57
>>> >> rozcestníků
>>> >> Pražák
>>> >> ___
>>> >> 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
>>
>>
>>
>> ___
>> 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-ph] Missing Road

[Jim Morgan]

This is odd. The end of Polaris street and the whole of Orion street are 
missing. 


http://www.openstreetmap.org/?mlat=14.56256=121.03101#map=19/14.56256/121.03101

I deleted and recreated Orion street, but that still didn't prompt it to 
re-appear. 

Any ideas? Also, you used to be able to right click on the map to load the 
image. Seems like OSM has hijacked the right click menu. 

The image in question is this one.
http://b.tile.openstreetmap.org/19/438408/240703.png

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

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Uwe Sennewald]

Habt ihr schon mal was von LEMnet ( http://www.lemnet.org/de ) gehört ?
Die nutzen OSM , müllen es aber mit den Informationen zu den 
Ladestationen nicht voll.

Senni

Am 28.03.2017 um 10:29 schrieb Max:
> Herzlichen Dank für die übersichtliche Zusammenstellung zum Thema. Hat 
> mich bislang als nicht betroffenen wenig interessiert und ist wohl 
> deshalb an mir vorbei gegangen.
>
> On 2017년 03월 28일 05:57, Harald Hartmann wrote:
>>> Alles in allem: das Thema Elektromobilität ist wirklich noch sehr
>>> ausbaufähig in Deutschland.
>>
>> Jepp, alles bekannt, wurde auch bereits im Forum mehrfach diskutiert:
>> - Bitte amenity=charging_station rendern [1]
>> - Wie Ladestationen (amenity=charging_station) für Autos erkennen? [2]
>> - etankstellen - Hilfe bei der Datenerfassung [3]
>>
>> [1] https://forum.openstreetmap.org/viewtopic.php?id=54525
>> [2] https://forum.openstreetmap.org/viewtopic.php?id=54928
>> [3] https://forum.openstreetmap.org/viewtopic.php?id=56744
>>
>>> Für OSM stellt sich hier die Frage:
>>> Wie bildet man das sinnvol ab? Welche tags werden hier gesetzt?
>>
>> http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dcharging_station
>>
>>> Und für die OSM daten-konsumenten:
>>> Wie gestaltet man die User-Experience für jemanden, der die nächste
>>> Ladestation sucht und dann da auch laden will?
>>
>> Da es ja gleich mehrere Variablen sind - könnte auch schon in OsmAnd
>> langsam eng werden für einen eigenen Filter (den man aber selbst
>> irgendwie zusammenbauen müsste) - eventuell durch eine Spezial-App ...
>> die wird es aber erst geben, wenn genug brauchbare Daten zum Filtern da
>> sind :-/ (Henne-Ei-Problem)
>>
>> Es braucht also am Anfang genug Enthusiasten, die so etwas einpflegen
>> ... übrigens die Autogas-Fahrer haben ähnliche Probleme. Und auch für
>> normale Tankstellen gibt es immer wieder mal Wünsche nach einer
>> Wochenaufgabe [5]
>>
>> [5] https://forum.openstreetmap.org/viewtopic.php?id=55813
>>
>> In dieser Diskussion wurde auch beschrieben, wie die gerade aktuell ohne
>> irgendeine App trotzdem deine passenden Ladestationen (wenn denn schon
>> alle Daten da wären) finden könntest: einfach eine entsprechende
>> Overpass Abfrage schreiben ;)
>>
>> ___
>> 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


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

Re: [Talk-GB] Layby restricted to abnormal loads

[Adam Snape]

As bicycles are vehicles (and not all other vehicles are motorised) that
can be tagged as vehicle=no hgv=yes. Given that the exclusion likely
includes more than just vehicles (eg. horses) , access=no foot=yes hgv=yes
is maybe a better option.

Adam

On 30 Mar 2017 7:29 a.m., "Warin" <61sundow...@gmail.com> wrote:

> On 30-Mar-17 05:00 PM, David Woolley wrote:
>
>> On 29/03/17 21:32, ael wrote:
>>
>>> and, for good measure, hgv=permissive.
>>>
>>
>> Permissive sounds wrong to me.  Permissive basically reflects the rights
>> of the land owner, and for users is the same as yes.
>>
>> ___
>>
>
> And it has no banned other vehicles ...so
>
> motor_vehicle=no
> bicycle=no
> hgv=yes
>
> ?
>
>
>
> ___
> 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: [Talk-cz] kontrola spárovanosti rozcestníků

[Zdeněk Pražák]

no jo omlouvám se že mne to nenapadlo
Pražák

-- Původní zpráva --
Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 29. 3. 2017 20:40:57
Předmět: Re: [Talk-cz] kontrola spárovanosti rozcestníků

"

Ahoj, to tam je odjakziva:



http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cor
(http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cor)




resp v radku show je to img+noref




Bye



On Mar 29, 2017 18:30, "Zdeněk Pražák"  wrote:
"
bylo by možné při kontrole spárovanosti rozcestníků na http://osm.fit.vutbr.
cz/OsmHiCheck/gp/?all(http://osm.fit.vutbr.cz/OsmHiCheck/gp/?all) vyčlenit
zvlášt tabulku s rozcestníky, které mají fotku a nemají ref

Pražák


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

"




___
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-GB] Layby restricted to abnormal loads

[Warin]

On 30-Mar-17 05:00 PM, David Woolley wrote:

On 29/03/17 21:32, ael wrote:

and, for good measure, hgv=permissive.


Permissive sounds wrong to me.  Permissive basically reflects the 
rights of the land owner, and for users is the same as yes.


___ 


And it has no banned other vehicles ...so

motor_vehicle=no
bicycle=no
hgv=yes

?



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

[Talk-TW] Fwd: Last chance! Submit a talk proposal for SotM 2017!

[Dongpo Deng]

給有興趣參加的人!
4月2日是裁稿日喔!

Dongpo

-- Forwarded message -
From: State of the Map Team 
Date: Wed, Mar 29, 2017 at 4:34 AM
Subject: Last chance! Submit a talk proposal for SotM 2017!
To: 



Last chance to submit your talk or workshop proposal for State of the Map
2017!

This year's State of the Map conference

will take place in Aizu-Wakamatsu, Japan. This is a gentle reminder to send
in your proposals for talks and/or workshops if you have not already done
so.

*The d**eadline to submit your session proposal is Sunday, 2nd April 2017.*

You are encouraged to submit proposals for 20 minute talks, 5 minute
lightning talks, and 75 minute workshops that will result in progress and
excitement in the world of OpenStreetMap.

Please apply here

!

Thank you,
*Your State of the Map team*

If you have any questions, please contact us at t...@stateofthemap.org

Interested in sponsorship opportunities? Please contact us at
spons...@stateofthemap.org





*Copyright © 2017 OpenStreetMap Foundation, All rights reserved.*
You are receiving this email because you signed up for the State of the Map
newsletter!

*Our mailing address is:*
OpenStreetMap Foundation
132 Maney Hill Road
Sutton Coldfield, West Midlands B72 1JU
United Kingdom

Add us to your address book



Want to change how you receive these emails?
You can update your preferences

or unsubscribe from this list


[image: Email Marketing Powered by MailChimp]

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

Re: [Talk-GB] Layby restricted to abnormal loads

[David Woolley]

On 29/03/17 21:32, ael wrote:

and, for good measure, hgv=permissive.


Permissive sounds wrong to me.  Permissive basically reflects the rights 
of the land owner, and for users is the same as yes.


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