Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

Ahoj,
Dne 24.2.2018 v 01:21 r00t napsal(a):
> Ahoj,
>
> Systematicky mapuju schranky v Praze a obcas narazim na to ze nekdo schranku 
> asi
> podle POI importeru dal do mapy, ale uz ji nikam neposunul. Takze je treba
> uprostred domu nebo stredu ulice. Tyhle schranky se daji detekovat podle 
> posunu,
> pokud ukazuje "Posunuto o 0.0 cm" tak je s nejvetsi pravdepodobnosti spatne,
> pochybuju ze by nekde data posty mely takovou presnost :)
> Naposledy jsem tohle videl u 10003:9.
>
> Je mozne ze je to proste nepozornost (chci zmapovat schranku, potom ji tam ale
> nikde nenajdu, ale uz zapomenu smazat vlozeny bod) nebo proste nepochopeni 
> toho
> jak POI importer funguje.
> Ale mozna by tohle chtelo nejak detekovat, protoze jinak se jevi schranka jako
> zelena a hotova.
>
> Nekolik dalsich divnosti:
>  19007:2083 - v datech od posty nejsou dny v tydnu, jenom 08:00. Vsechny 
> okolni
>  maji "Mo-Fr 08:00". Kvuli tomu sviti zlute jako castecne hotova.

Díky za info. Problém je v datech. Mezi "Měšická 822" a "Bášť" je
středník, ale měla by tam být čárka.
Tím se to celé posune:

19007;Depo Praha 703;2083;Měšická 822, 25065,
Bašť;1030936.3;736587.07;Měšická 822; Bášť08:00;1-5 - pracovní dny
(pondělí až pátek)
19007;Depo Praha 703;2085;č.p. 23, 25065,
Sedlec;1032534.01;738715.79;Prodejna, Sedlec 2308:00;1-5 - pracovní
dny (pondělí až pátek)



Mirku, můžeš to prosím vyreklamovat? ;-)
Díky

>  19007:2056 - Husova , Sedlčánky - tohle nedava moc smysl, v Sedlčánkach zadna
>  husova ulice neni a cele jsem je projel pomoci streetview/panoramy a zadnou
>  schranku nenasel. Husova je ulice ve vedlejsich Celakovich, ale ani tam zadna
>  schranka neni.

Dvě možnosti:
1) Mirek poprosí poštu o upřesnění polohy
2) Uděláš si výlet do Sedlčánek a zeptáš se někoho místního, kde tam
mají schránku :-D
Sedlčánky patří pod Čelákovice a vypadají, že by si schránku zasložily.
>  19007:1988 - schranka tam byla, ale budova zbourana a na nove neni. Nikde v
>  okoli na streetview nenalezena.

Opět ideální tip na výlet ;-)

> ...jeste by se asi neco naslo, ale tohle je zatim vsechno co si pamatuju...

Někam si to sepiš a pak to pošlem přes Mirka na poštu.

Možná bych do těch statistik mohl přidat možnost přidat ke schránce
komentář. Ale to bych musel nejprve nastudovat jak funguje oauth ;-)
Marián


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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Yes, but this rendering does not change when a road crosses a border ^^

djakk


Le sam. 24 févr. 2018 à 05:43, JB  a écrit :

> There is something I don't get.
> Draw primary the same color as trunk and you have no more «
> discontinuity »?
> In France, some commercial map (the most sold, I think) use a different
> rendering for trunk and primary, because you drive faster on trunks. I
> like it, I think they like it, because they have been using this
> rendering for decades.
> JB.
>
> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
> > As an exercise (and I'm curious about your thoughts on this), I found
> > the main routes between place=city within Czechia (didn't have time to
> > include cities in adjacent countries, bear that in mind).
> >
> > Here's the result [1] using the old colour scheme (motorway=blue,
> > trunk=green, primary=red; with a little mistake: secondary=yellow).
> > Top image uses the current classifications, and bottom image is the
> > result if city-city routes are classified as trunks. Looks very
> > similar to most other maps. Just by looking at it, it's quite obvious
> > which is the main route between each pair of cities. As expected, the
> > method also found out the best ways through and around Praha when
> > going across it. This could also be slightly improved - for example,
> > with little extra time, it is easier to recommend going through route
> > 6 and then Karlovarská than through route 5 and Bucharova.
> >
> > I've checked the three small secondary segments using Street View.
> > Their physical structure is quite good. If still considered
> > undersirable, there are alternative main ways that increase the total
> > time of travel very slightly. Not all routers agreed on taking them
> > anyway.
> >
> > [1] https://i.imgur.com/qFGSveX.jpg
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[JB]

There is something I don't get.
Draw primary the same color as trunk and you have no more « 
discontinuity »?
In France, some commercial map (the most sold, I think) use a different 
rendering for trunk and primary, because you drive faster on trunks. I 
like it, I think they like it, because they have been using this 
rendering for decades.

JB.

Le 24/02/2018 à 04:45, Fernando Trebien a écrit :

As an exercise (and I'm curious about your thoughts on this), I found
the main routes between place=city within Czechia (didn't have time to
include cities in adjacent countries, bear that in mind).

Here's the result [1] using the old colour scheme (motorway=blue,
trunk=green, primary=red; with a little mistake: secondary=yellow).
Top image uses the current classifications, and bottom image is the
result if city-city routes are classified as trunks. Looks very
similar to most other maps. Just by looking at it, it's quite obvious
which is the main route between each pair of cities. As expected, the
method also found out the best ways through and around Praha when
going across it. This could also be slightly improved - for example,
with little extra time, it is easier to recommend going through route
6 and then Karlovarská than through route 5 and Bucharova.

I've checked the three small secondary segments using Street View.
Their physical structure is quite good. If still considered
undersirable, there are alternative main ways that increase the total
time of travel very slightly. Not all routers agreed on taking them
anyway.

[1] https://i.imgur.com/qFGSveX.jpg

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



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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

As an exercise (and I'm curious about your thoughts on this), I found
the main routes between place=city within Czechia (didn't have time to
include cities in adjacent countries, bear that in mind).

Here's the result [1] using the old colour scheme (motorway=blue,
trunk=green, primary=red; with a little mistake: secondary=yellow).
Top image uses the current classifications, and bottom image is the
result if city-city routes are classified as trunks. Looks very
similar to most other maps. Just by looking at it, it's quite obvious
which is the main route between each pair of cities. As expected, the
method also found out the best ways through and around Praha when
going across it. This could also be slightly improved - for example,
with little extra time, it is easier to recommend going through route
6 and then Karlovarská than through route 5 and Bucharova.

I've checked the three small secondary segments using Street View.
Their physical structure is quite good. If still considered
undersirable, there are alternative main ways that increase the total
time of travel very slightly. Not all routers agreed on taking them
anyway.

[1] https://i.imgur.com/qFGSveX.jpg

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Fri, Feb 23, 2018 at 7:30 PM, Matej Lieskovský
 wrote:
> Ok, look here: https://www.openstreetmap.org/#map=16/50.3124/13.8720
> The highway=trunk section is a bypass built to motorway specification. It is
> not even a motorroad, because it is so short, but the change in the
> character of the road is immense - it goes from 2 lanes to 2+2 lanes with a
> median, gets wider borders, no pedestrians, cyclists or agricultural
> vehicles allowed... The fact that it is drawn as a trunk road hints at all
> these changes.

You could also map it with lanes=4+foot=no+bicycle=no+agricultural=no
and let the renderer decide whether these things are worthy of special
representation or not.

As a map user, I'm left with a bad impression of a map with such
discontinuities, it looks messy and unprofessional. None of the
commercial alternatives to OSM have such artifacts. You may also look
for other maps of Czechia on Google Images and most won't show
artifacts like that either. Also look at the classification of
England, Australia and Russia in OSM and you won't find any similar
artifacts. I doubt their roads never change structure over long
distances.

> On 23 February 2018 at 23:18, Fernando Trebien 
> wrote:
>>
>> Wouldn't the estimate change often? We usually don't like that in OSM. [1]
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features
>>
>> On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský
>>  wrote:
>> > A "traffic" tag sounds like a good idea, but I'd have two suggestions:
>> > 1) Can we find a better name?
>> > 2) Estimates are better than words. I can imagine what 5000 cars per day
>> > look like, but what is considered heavy traffic in (for example) Brazil?
>> >
>> > I'm all for letting highway tag only worry about high-level stuff
>> > (footway,
>> > cycleway, road, path...)  and have a separate class tag for official
>> > classification where needed.
>> >
>> > I've created this page:
>> > https://wiki.openstreetmap.org/wiki/Highway_classes
>> > Feel free to add your region!
>> >
>> > PS: +1 to Michael's point about not changing classifications in
>> > countries
>> > with an official system.
>> >
>> > On 23 February 2018 at 23:06, Michael Andersen  wrote:
>> >>
>> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:
>> >>
>> >> > Assuming the map is correctly classified in Europe, I'm seeing many
>> >> > fragments of motorways and trunks all over the map. Is this an
>> >> > artifact of local definitions? Or is it intentional and desirable?
>> >>
>> >> The "fragments" of trunks you see in Denmark are intentional and
>> >> desirable. We
>> >> follow the official classifications. We will not be happy to see you
>> >> change them.
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> talk mailing list
>> >> talk@openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/talk
>> >
>> >
>> >
>> > ___
>> > talk mailing list
>> > talk@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk
>> >
>>
>>
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "Nullius in verba."
>
>



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Jérôme Amagat]

Le 23 février 2018 à 22:13, marc marc  a écrit :

> Le 23. 02. 18 à 14:55, Jérôme Amagat a écrit :
> > comment ont fait pour différencier par exemple les Alpes et un de ses
> > massifs?
>
> name=Les Alpes <> name=le nom du massif ? :)
>

Je parler bien sur de comment l'afficher sur un rendu ou comment s'en
servir d'une façon ou d'une autre si ce n'est qu'un node. (c'est pareil
avec le node name=Paris et name="un petit hameau" avec le nom on voit la
différence mais ça suffit pas)

>
> > Un truc que je trouverais pas mal c'est créer une relation multipolygon
> > avec des membres qui ont des rôles du type "outer_approximatif" voir
> > "outer_approximatif:1000m" par exemple,
>
> comme la limite de 1000m est elle même approximative, on pourrait faire
> un tag qui donne l'approximation de l'approximatif, genre 1000m+-100m
>
> blague à part, c'est entrain de devenir une usine à gaz (donc inutilisé).
>
> si le nœud ne convient pas
> un polygone avec source:geometry=estimated + note=de manière totalement
> invérifiable je pense que l'approximation est d'environ 1000m
> cela ne semble pas plus simple et plus "standard" ?
> Il y a plusieurs régions des alpes qui sont décrites ainsi dans osm
> (sans la note)
>

Une usine a gaz? il y a juste une chose qui change c'est le rôle d'un
membre du multipolygon. (ce que je pensais avec ce 1000m c'est que c’était
déjà un plus ou moins 1000m pour la limite)
tu proposes bien d'ajouter quelque chose aussi, cette note. si c'est une
note c'est impossible à réutiliser.
d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
Philippe je sais qu'il faut de l'anglais) c'est le bon mot. vu que le
problème c'est pas que l'on sais pas où est exactement la limite c'est que
la limite est flou.
Placer un au plus grand et un au plus petit je ne vois pas trop comment ça
réglerait le problème sauf qu'il y aurait 2 fois plus de way placé
approximativement.
Placer un tag sur la relation pourquoi pas mais on ne pourra pas avoir le
fait que certaine partie du contour sont connu précieusement comme une
rivière peut servir de limite à un massif de montagne et d'autres sont très
approximative.
Placer un tag sur le way qui fait parti de la relation : si le way sert à
plusieurs choses comment savoir que le tag sert à cette relation et pas à
autre chose.


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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[r00t]

Ahoj,

Systematicky mapuju schranky v Praze a obcas narazim na to ze nekdo schranku asi
podle POI importeru dal do mapy, ale uz ji nikam neposunul. Takze je treba
uprostred domu nebo stredu ulice. Tyhle schranky se daji detekovat podle posunu,
pokud ukazuje "Posunuto o 0.0 cm" tak je s nejvetsi pravdepodobnosti spatne,
pochybuju ze by nekde data posty mely takovou presnost :)
Naposledy jsem tohle videl u 10003:9.

Je mozne ze je to proste nepozornost (chci zmapovat schranku, potom ji tam ale
nikde nenajdu, ale uz zapomenu smazat vlozeny bod) nebo proste nepochopeni toho
jak POI importer funguje.
Ale mozna by tohle chtelo nejak detekovat, protoze jinak se jevi schranka jako
zelena a hotova.

Nekolik dalsich divnosti:
 19007:2083 - v datech od posty nejsou dny v tydnu, jenom 08:00. Vsechny okolni
 maji "Mo-Fr 08:00". Kvuli tomu sviti zlute jako castecne hotova.
 19007:2056 - Husova , Sedlčánky - tohle nedava moc smysl, v Sedlčánkach zadna
 husova ulice neni a cele jsem je projel pomoci streetview/panoramy a zadnou
 schranku nenasel. Husova je ulice ve vedlejsich Celakovich, ale ani tam zadna
 schranka neni.
 19007:1988 - schranka tam byla, ale budova zbourana a na nove neni. Nikde v
 okoli na streetview nenalezena.

...jeste by se asi neco naslo, ale tohle je zatim vsechno co si pamatuju...


J.


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

Re: [OSM-talk] [Diversity-talk] [HOT] LGBTQ people at HOT Summit?

[Blake Girardot]

Hi Rory,

Again, I really appreciate you bringing up this issue. I do not want
to derail, in fact I very much want to continue the discussion.

But on a process note: Trying to have it across 3 lists is not working
very well because all the contributors to this thread are not
subscribed to all three lists so few, if any folks can follow the
whole thread because numerous replies are being bounced because for
example, you and baloo are not on the HOT email list, so for example,
that list will only see this reply I am typing now (unless a list
moderator passes them through, but I am not on duty 24/7 to do that).

Could we arrange to carry on the conversation on one list so everyone
interested can join that list and participate? Then everyone can also
feel confident their replies are seen by everyone who is interested as
well instead of some replies being seen by some email list members as
not being replied to, etc.

Respectfully,
blake

On Fri, Feb 23, 2018 at 10:05 PM, Rory McCann  wrote:
> Hi
>
> I always presumed this was caused by people not considering it, rather
> than active malice. Straight privilege, eh? :)
>
> Yes there are limitations with holding events in NA/Europe, both legal
> (immigration systems) and practical (higher relative cost). SotMs'
> scholarship programmes are attempt to acknowledge and address this. And
> we should do better, and keep these barrier(s) in mind. There are
> countries in the global south, in Africa, where homosexuality is legal BTW.
>
> Some concrete, constructive suggestions:
>
> Inform any/all LGBTQ attendees that they need to go to Narnia (i.e. deep
> in the closet). This might be impossible for some (e.g. trans people).
> People should consider locking down their social media accounts, and
> consider what apps or photos they have on their phones. One run in with
> the police, and they look at your phone, and it's game over. (I didn't
> do this when I went to Tanzania, but I did when considering going to Iran).
>
> First option: Make this a no-LGBTQ event. Remove references to "sexual
> orientation" and "gender identity" from the CoC. Allow homophobic and
> transphobic harassment/abuse/insults at the event.
>
> Second option: Try to make this event as LGBTQ-friendly /as possible/.
> Reword the CoC to demote "sexuality" & "gender identity" sections to
> reflect this, and acknowledge that not all (homo/transphobic) incidents
> are actionable. i.e. Allow certain amounts of homophobic or transphobic
> insults/etc at the event.
>
> Your CoC already says police will only be contacted if the complainant
> wants it, that's good. I suggest another rule: "Don't report any
> attendees (& friends/family) to the police for LGBTQ activity"[0].
>
> In the last few months, the Tanzanian government[1][2], and police, have
> announced a crackdown on gay rights, and they're implementing it.
> Arresting LGBTQ people[3][4], and owners of venues[5], which host
> pro-LGBTQ events, and shutting down NGOs which promote LGBTQ
> rights[6][7].
>
> Can you trust the venue to not inform the police? If there's a dispute
> and you want to remove someone from the event, what will any local
> security staff, or local volunteers, do with those threats hanging over
> them? Be conscience that if you get the police involved in any incident,
> the accused might points out a homosexual in the mist to deflect
> attention & discredit your organization.
>
> LGBTQ people can go to Tanzania. But the organizers ability to enforce a
> CoC in this area is severely limited. This is why you cannot continue to
> call it a (LGBTQ) safe space.
>
> Good luck.
>
> Rory
>
> --
>
> [0] Specific wording. A general "don't call police" enables abusers
> https://mjg59.dreamwidth.org/46791.html
>
> [1] 'Seeds of hate' sown as Tanzania starts LGBT crackdown. The
> Guardian, 8 August 2016
> https://www.theguardian.com/world/2016/aug/08/seeds-of-hate-sown-as-tanzania-starts-lgbt-crackdown
>
> [2] Tanzania suspends HIV/AIDS programs in new crackdown on gays.
> Chicago Tribune, 23 November 2016
> http://www.chicagotribune.com/news/nationworld/ct-tanzania-crackdown-on-gays-20161123-story.html
>
> [3] Lesbianism lands four people in Mwanza court. The Citizen, 9
> December 2017
> http://www.thecitizen.co.tz/News/Lesbianism-lands-four-people-in-Mwanza-court/1840340-4220972-11ewf0x/index.html
>
> [4] Police arrest woman in Tanzania over video of same-sex kiss.
> Reuters, 2 December 2017.
> https://www.reuters.com/article/us-tanzania-lgbt/police-arrest-woman-in-tanzania-over-video-of-same-sex-kiss-idUSKBN1DW0FP
>
> [5] Zanzibar police nab 20 over homosexuality. Daily News, 17 September 2017
> https://www.dailynews.co.tz/index.php/home-news/53017-zanzibar-police-nab-20-over-homosexuality
>
> [6] State suspends NGO supporting gay marriages. Daily News, 21 October 2017
> https://www.dailynews.co.tz/index.php/home-news/53703-state-suspends-ngo-supporting-gay-marriages
>
> [7] Nchemba: We’ve no room for gays. Daily 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

The change is usually on the order of single digit percent per year, making
even a decade old estimate much more representative than "heavy".
Seriously, "traffic=trunk" obviously means nothing if we cannot agree on
what "highway=trunk" means.


Ok, look here: https://www.openstreetmap.org/#map=16/50.3124/13.8720
The highway=trunk section is a bypass built to motorway specification. It
is not even a motorroad, because it is so short, but the change in the
character of the road is immense - it goes from 2 lanes to 2+2 lanes with a
median, gets wider borders, no pedestrians, cyclists or agricultural
vehicles allowed... The fact that it is drawn as a trunk road hints at all
these changes.

On 23 February 2018 at 23:18, Fernando Trebien 
wrote:

> Wouldn't the estimate change often? We usually don't like that in OSM. [1]
>
> [1] https://wiki.openstreetmap.org/wiki/Good_practice#Don.
> 27t_map_temporary_events_and_temporary_features
>
> On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský
>  wrote:
> > A "traffic" tag sounds like a good idea, but I'd have two suggestions:
> > 1) Can we find a better name?
> > 2) Estimates are better than words. I can imagine what 5000 cars per day
> > look like, but what is considered heavy traffic in (for example) Brazil?
> >
> > I'm all for letting highway tag only worry about high-level stuff
> (footway,
> > cycleway, road, path...)  and have a separate class tag for official
> > classification where needed.
> >
> > I've created this page: https://wiki.openstreetmap.
> org/wiki/Highway_classes
> > Feel free to add your region!
> >
> > PS: +1 to Michael's point about not changing classifications in countries
> > with an official system.
> >
> > On 23 February 2018 at 23:06, Michael Andersen  wrote:
> >>
> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:
> >>
> >> > Assuming the map is correctly classified in Europe, I'm seeing many
> >> > fragments of motorways and trunks all over the map. Is this an
> >> > artifact of local definitions? Or is it intentional and desirable?
> >>
> >> The "fragments" of trunks you see in Denmark are intentional and
> >> desirable. We
> >> follow the official classifications. We will not be happy to see you
> >> change them.
> >>
> >>
> >>
> >>
> >> ___
> >> talk mailing list
> >> talk@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

Wouldn't the estimate change often? We usually don't like that in OSM. [1]

[1] 
https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features

On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský
 wrote:
> A "traffic" tag sounds like a good idea, but I'd have two suggestions:
> 1) Can we find a better name?
> 2) Estimates are better than words. I can imagine what 5000 cars per day
> look like, but what is considered heavy traffic in (for example) Brazil?
>
> I'm all for letting highway tag only worry about high-level stuff (footway,
> cycleway, road, path...)  and have a separate class tag for official
> classification where needed.
>
> I've created this page: https://wiki.openstreetmap.org/wiki/Highway_classes
> Feel free to add your region!
>
> PS: +1 to Michael's point about not changing classifications in countries
> with an official system.
>
> On 23 February 2018 at 23:06, Michael Andersen  wrote:
>>
>> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:
>>
>> > Assuming the map is correctly classified in Europe, I'm seeing many
>> > fragments of motorways and trunks all over the map. Is this an
>> > artifact of local definitions? Or is it intentional and desirable?
>>
>> The "fragments" of trunks you see in Denmark are intentional and
>> desirable. We
>> follow the official classifications. We will not be happy to see you
>> change them.
>>
>>
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

A "traffic" tag sounds like a good idea, but I'd have two suggestions:
1) Can we find a better name?
2) Estimates are better than words. I can imagine what 5000 cars per day
look like, but what is considered heavy traffic in (for example) Brazil?

I'm all for letting highway tag only worry about high-level stuff (footway,
cycleway, road, path...)  and have a separate class tag for official
classification where needed.

I've created this page: https://wiki.openstreetmap.org/wiki/Highway_classes
Feel free to add your region!

PS: +1 to Michael's point about not changing classifications in countries
with an official system.

On 23 February 2018 at 23:06, Michael Andersen  wrote:

> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:
>
> > Assuming the map is correctly classified in Europe, I'm seeing many
> > fragments of motorways and trunks all over the map. Is this an
> > artifact of local definitions? Or is it intentional and desirable?
>
> The "fragments" of trunks you see in Denmark are intentional and
> desirable. We
> follow the official classifications. We will not be happy to see you
> change them.
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

I don't intend to.

But I still wonder why they are desirable.

On Fri, Feb 23, 2018 at 7:06 PM, Michael Andersen  wrote:
> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:
>
>> Assuming the map is correctly classified in Europe, I'm seeing many
>> fragments of motorways and trunks all over the map. Is this an
>> artifact of local definitions? Or is it intentional and desirable?
>
> The "fragments" of trunks you see in Denmark are intentional and desirable. We
> follow the official classifications. We will not be happy to see you change 
> them.
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Michael Andersen]

On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote:

> Assuming the map is correctly classified in Europe, I'm seeing many
> fragments of motorways and trunks all over the map. Is this an
> artifact of local definitions? Or is it intentional and desirable?

The "fragments" of trunks you see in Denmark are intentional and desirable. We 
follow the official classifications. We will not be happy to see you change 
them.




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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Fri, Feb 23, 2018 at 5:25 PM, Mark Wagner  wrote:
> Which one is the "best"?  If it's the fast route, there's no issue:
> both roads are already "highway=motorway".

I think the fastest route is almost always what most people would
consider the best. The exception (probably rare/non-existent in the
US) would be when the fastest route has infrastructure problems - say,
it is a dirt road - while there are nearby routes with fewer problems
(say a paved road that takes a little extra time because it is
significantly longer).

That being an exception, the local community can the discuss the
exception (in the forum, so that it can be linked to from the map) and
vote against making it the main route.

> Fargo and Rapid
> City are both larger than any city within 200 miles, which would
> seem to make them "large/important", but even by western American
> standards, they're pretty small in an absolute sense.

I propose that place=* implies importance. Fargo has 105k inhabitants
(place=city), Rapid City has 67k inhabitants (place=town). One highway
class would connect cities (city-city), a lower class would connect
towns and above (town-town, town-city), so the class of the ways
making up the route between those places would be of the second class.
If cities are connected by trunk and towns by primary, then the route
between them would be primary.

Now, which is the best route? Google insists on going through
McIntosh, whereas Here.com and Waze prefer going through Sioux Falls
or Dickinson depending on which direction you're going (mostly because
the roads in the area are nearly a grid, which is a characteristic of
the US that is not typical of most countries - that's worthy of some
discussion). Nonetheless, there are few options to choose from. Google
is the dissonant view, so maybe it should be initially ignored. The
route through Sioux Falls is part of other routes between pairs of
towns (say Sioux City - Grand Forks), so it must be a town-town route
for at least that other reason. The remaining question then is whether
the route Dickinson - Rapid City should be a town-town route.
Dickinson has 17k inhabitants, so it is a town, so that route should
be a town-town route. Which one is the main route between Fargo and
Rapid City is then not relevant because both options are town-town
routes for other reasons. If the situation did not allow us to ignore
the problem, the next step would be to collect data (tracklogs), or
publicly agree that both routes should be considered important because
they're too similar (one possible improvement for the method).

It should be noted that the route between Sioux Falls and Fargo would
end up being classified as a city-city route because it is part of the
main route between Kansas City (place=city, 459k people) and Winnipeg
(place=city, 705k people).

What if going through McIntosh is really the main route, or if all
three routers are wrong? In that case, the initial analysis would be
incorrect and the community would need to discuss that particular case
and document it. It is possible that routers in the OSM ecosystem
(OSRM, GraphHopper) can be used as long as relevant properties
(maxspeed=*, and in places with deficitary infrastructure, surface=*)
of route alternatives are mapped in OSM so that the routers can take
them into account.

What if, instead of the US, one is mapping in the UK, where place=* is
defined according to public ordinances. In that case, the method still
works, it just will judge a place's importance using another criterion
instead of population.

> Trunk, primary,
> or secondary?
>
> --
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[marc marc]

Bonjour,

Le 23. 02. 18 à 12:31, Christian Quest a écrit :
> JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5 
> objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets).

La limite du changeset a été baissé de 50k à 10k l'an passé
https://wiki.openstreetmap.org/w/index.php?title=API_v0.6=next=1431627
$ wget -q -O - https://api.openstreetmap.org/api/capabilities
 
josm sait gérer les multiples changeset  mais il a aussi un mode
qui n’envoie qu'un changeset, c'est peut-être cela qui s'est passé.

> Le 23 février 2018 à 11:26, Rpnpif a écrit :
> Le but était d'abord et avant tout de placer les ruisseaux manquants.
> Mais aucun way n'a été tranféré.

sélectionne UN ruisseau manquant et fait "menu fichier, envoyer
la sélection". la fenêtre d'envois te dit le nom d'objet modifiés.
si ce nombre est déraisonnable (genre >100) annule l'envoi.
la fen
Sinon met une description (par exemple le nom du ruisseau) et valide.

> J'ai bien noté ce que recommande Marc Marc à propos de l'attribut
> sources. Mais dans ce cas où doit-on mettre le source dans JOSM ?

source juste sur le changeset
rien sur les noeuds
sur les way le tag qui décrit le type de rivière et son nom.

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

Re: [OSM-talk-fr] Zones géographiques informelles

[marc marc]

Le 23. 02. 18 à 14:55, Jérôme Amagat a écrit :
> comment ont fait pour différencier par exemple les Alpes et un de ses 
> massifs?

name=Les Alpes <> name=le nom du massif ? :)

> Un truc que je trouverais pas mal c'est créer une relation multipolygon 
> avec des membres qui ont des rôles du type "outer_approximatif" voir 
> "outer_approximatif:1000m" par exemple, 

comme la limite de 1000m est elle même approximative, on pourrait faire 
un tag qui donne l'approximation de l'approximatif, genre 1000m+-100m

blague à part, c'est entrain de devenir une usine à gaz (donc inutilisé).

si le nœud ne convient pas
un polygone avec source:geometry=estimated + note=de manière totalement 
invérifiable je pense que l'approximation est d'environ 1000m
cela ne semble pas plus simple et plus "standard" ?
Il y a plusieurs régions des alpes qui sont décrites ainsi dans osm 
(sans la note)

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

Re: [Talk-es] Carretera sin línea central

[Jorge Sanz Sanfructuoso]

Dónde está indicado eso de que por tener un carril sea oneway a la fuerza?
No tiene porqué.

El vie., 23 feb. 2018 18:10, Javier Sánchez Portero 
escribió:

> Si pones lanes=1 implica oneway=yes. Es una carretera de doble sentido.
>
> El 23 de febrero de 2018, 17:00, Jorge Sanz Sanfructuoso <
> sanc...@gmail.com> escribió:
>
>> Yo esas las pongo como lanes=1, no hace falta poner oneway=no . Ya indica
>> lo que es con eso.
>>
>> El vie., 23 feb. 2018 a las 17:55, Javier Sánchez Portero (<
>> javiers...@gmail.com>) escribió:
>>
>>> Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se
>>> cual sería el término adecuado en inglés.
>>>
>>> El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega <
>>> i...@sanchezortega.es> escribió:
>>>
 On 2018-02-23 14:51, Javier Sánchez Portero wrote:

> Hola
>
> Hay sitios rurales en los que las carreteras no tienen pintada línea
> central. Pueden ser unclassified, tertiary o incluso secondary. Por
> supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
> etiqueta para indicarlo? El método más heavy sería lanes=1
> oneway=no, pero me resulta.
>

 Creo que se trata de carreteras de dos carriles (uno por sentido), sin
 separación por marcas viales.

 Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:

 En las calzadas con doble sentido de circulación y dos carriles,
> SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.
>

 Es decir, es perfectamente posible una carretera con calzada de doble
 sentido y un carril para cada sentido de la circulación, aun cuando no haya
 señales horizontales (línea pintada) que los separen.


 [1]
 http://www.dgt.es/es/seguridad-vial/normativa-y-legislacion/reglamento-trafico/circulacion-general/normas-basicas/

 --
 Iván Sánchez Ortega 

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

>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>> --
>> Jorge Sanz Sanfructuoso - Sanchi
>> Blog http://jorgesanz.es/
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanz.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-de] Dt. Kartenstil: Rendern von historic=fort

[Christoph Hormann]

On Friday 23 February 2018, Sven Geggus wrote:
>
> OSM carto rendert seit der aktuellen Version für den tag
> historic=fort folgendes Symbol:
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbo
>ls/fort.svg
>
> Aus meiner Sicht sieht das irgendwie aus wie eine Spielzeugburg von
> Playmobil oder so.

Das Problem ist hier nicht nur das Symbol, sondern auch dass OSM-Carto 
hier klar die Aufgabe aus den Augen verloren hat, den Mapper bei der 
korrekten und konsistenten Verwendung von Tags zu unterstützen und eine 
Fragmentierung des Taggings zu vermeiden.

Wenn jetzt dort historic=fort (knapp 3000 Verwendungen) gerendert wird, 
historic=castle mit >37k Verwendungen und einem etablierten, recht gut 
nach kulturellen und architektonischen Kriterien definierten und auch 
verbreitet verwendeten Zusatztag (knapp 10k mal) jedoch nicht ist das 
recht kontraproduktiv.  

Ich fänd es im Grunde wahrscheinlich besser historic=fort nicht zu 
rendern, oder in einer Art und Weise, die nichts architektonisches 
impliziert.  Im Grunde ist ja so weit ich das verstehe jede 
Bunker-Ruine aus dem Krieg ein historic=fort + ruins=yes dafür wäre 
jetzt so ein Klischee-Burg-Symbol irreführend und wie schon angedeutet 
hinsichtlich Mapper-Feedback ziemlich kontraproduktiv (und daneben 
gerade für einen internationalen Stil im Grunde auch etwas peinlich).

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

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

Re: [OSM-talk] [HOT] LGBTQ people at HOT Summit?

[Rory McCann]

Hi

I always presumed this was caused by people not considering it, rather
than active malice. Straight privilege, eh? :)

Yes there are limitations with holding events in NA/Europe, both legal
(immigration systems) and practical (higher relative cost). SotMs'
scholarship programmes are attempt to acknowledge and address this. And
we should do better, and keep these barrier(s) in mind. There are
countries in the global south, in Africa, where homosexuality is legal BTW.

Some concrete, constructive suggestions:

Inform any/all LGBTQ attendees that they need to go to Narnia (i.e. deep
in the closet). This might be impossible for some (e.g. trans people).
People should consider locking down their social media accounts, and
consider what apps or photos they have on their phones. One run in with
the police, and they look at your phone, and it's game over. (I didn't
do this when I went to Tanzania, but I did when considering going to Iran).

First option: Make this a no-LGBTQ event. Remove references to "sexual
orientation" and "gender identity" from the CoC. Allow homophobic and
transphobic harassment/abuse/insults at the event.

Second option: Try to make this event as LGBTQ-friendly /as possible/.
Reword the CoC to demote "sexuality" & "gender identity" sections to
reflect this, and acknowledge that not all (homo/transphobic) incidents
are actionable. i.e. Allow certain amounts of homophobic or transphobic
insults/etc at the event.

Your CoC already says police will only be contacted if the complainant
wants it, that's good. I suggest another rule: "Don't report any
attendees (& friends/family) to the police for LGBTQ activity"[0].

In the last few months, the Tanzanian government[1][2], and police, have
announced a crackdown on gay rights, and they're implementing it.
Arresting LGBTQ people[3][4], and owners of venues[5], which host
pro-LGBTQ events, and shutting down NGOs which promote LGBTQ
rights[6][7].

Can you trust the venue to not inform the police? If there's a dispute
and you want to remove someone from the event, what will any local
security staff, or local volunteers, do with those threats hanging over
them? Be conscience that if you get the police involved in any incident,
the accused might points out a homosexual in the mist to deflect
attention & discredit your organization.

LGBTQ people can go to Tanzania. But the organizers ability to enforce a
CoC in this area is severely limited. This is why you cannot continue to
call it a (LGBTQ) safe space.

Good luck.

Rory

-- 

[0] Specific wording. A general "don't call police" enables abusers
https://mjg59.dreamwidth.org/46791.html

[1] 'Seeds of hate' sown as Tanzania starts LGBT crackdown. The
Guardian, 8 August 2016
https://www.theguardian.com/world/2016/aug/08/seeds-of-hate-sown-as-tanzania-starts-lgbt-crackdown

[2] Tanzania suspends HIV/AIDS programs in new crackdown on gays.
Chicago Tribune, 23 November 2016
http://www.chicagotribune.com/news/nationworld/ct-tanzania-crackdown-on-gays-20161123-story.html

[3] Lesbianism lands four people in Mwanza court. The Citizen, 9
December 2017
http://www.thecitizen.co.tz/News/Lesbianism-lands-four-people-in-Mwanza-court/1840340-4220972-11ewf0x/index.html

[4] Police arrest woman in Tanzania over video of same-sex kiss.
Reuters, 2 December 2017.
https://www.reuters.com/article/us-tanzania-lgbt/police-arrest-woman-in-tanzania-over-video-of-same-sex-kiss-idUSKBN1DW0FP

[5] Zanzibar police nab 20 over homosexuality. Daily News, 17 September 2017
https://www.dailynews.co.tz/index.php/home-news/53017-zanzibar-police-nab-20-over-homosexuality

[6] State suspends NGO supporting gay marriages. Daily News, 21 October 2017
https://www.dailynews.co.tz/index.php/home-news/53703-state-suspends-ngo-supporting-gay-marriages

[7] Nchemba: We’ve no room for gays. Daily News, 26 June 2017,
https://www.dailynews.co.tz/index.php/home-news/51447-nchemba-we-ve-no-room-for-gays


On 16/02/18 22:55, Rachel Levine wrote:
> Dear Rory,
> 
> 
> *
> 
> Thank you for bringing up this important issue. We recognize the very 
> legitimate concern you raised and deeply regret any challenges this may 
> present to some in our community. This was not our intention.
> 
> 
> When our working group made the decision, we were proud to announce the 
> first ever HOT Summit at one of our project sites, and the first ever 
> HOT Summit in Africa. One of the primary reasons for the decision was 
> inclusivity: with a number of our colleagues and community members being 
> unfairly denied visas in the last two years, this was a unique 
> opportunity to rotate the Summit to a non-North America/Europe location. 
> Our goal was simply to welcome so many of our friends and community 
> members who may have been previously left out; at the same time 
> fostering the growth and expansion of OpenStreetMap and FOSS in Africa.
> 
> 
> Community input was requested at all stages of the process as we began 
> meeting more than three months ago. This 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

I would tag the amount of traffic (official count or estimation) + the
width of the lanes (bidirectional with no hard shoulder ?) + an
appropriated renderer to show heavy traffic + narrow road with a thin red
stroke.


Le ven. 23 févr. 2018 à 21:28, Mark Wagner  a écrit :

> On Thu, 15 Feb 2018 16:14:42 -0200
> Fernando Trebien  wrote:
>
> > Landing on this discussion several months late. I've just heard of it
> > by reading a wiki talk page [1].
> >
> > Since 13 February 2009, the wiki [2] criticises highway classification
> > as problematic/unverifiable. This has also been subject to a lot of
> > controversy (and edit wars) in my local community (Brazil), especially
> > regarding the effect of (lack of) pavement.
> >
> > In trying to achieve greater consensus some years ago, I decided to
> > seek opinions elsewhere and finally I arrived at this scheme [3] which
> > I think is very useful, if not perfect yet. It can be easily
> > summarised like this:
> > - trunk: best routes between large/important cities
> > - primary: best routes between cities and above
> > - secondary: best routes between towns/suburbs and above
> > - tertiary: best routes between villages/neighbourhoods and above
> > - unclassified: best routes between other place=* and above
>
> "Best" and "large/important" are both rather subjective.  Further, this
> proposed system gives rather questionable results at times.
>
> For example, the fastest route between the cities of Fargo (largest city
> in North Dakota, population 120,000) and Rapid City (second-largest
> city in South Dakota, population 68,000) follows I-29 and I-90, while
> the shortest follows I-94 for a ways, then cuts cross-country on a mix
> of minor state highways to save 70 miles while taking about five minutes
> longer (on a total trip time of 470 minutes).
>
> Which one is the "best"?  If it's the fast route, there's no issue:
> both roads are already "highway=motorway".
>
> If it's the short route, how should it be classified?  Fargo and Rapid
> City are both larger than any city within 200 miles, which would
> seem to make them "large/important", but even by western American
> standards, they're pretty small in an absolute sense.  Trunk, primary,
> or secondary?
>
> --
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Mark Wagner]

On Thu, 15 Feb 2018 16:14:42 -0200
Fernando Trebien  wrote:

> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
> 
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
> 
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above

"Best" and "large/important" are both rather subjective.  Further, this
proposed system gives rather questionable results at times.

For example, the fastest route between the cities of Fargo (largest city
in North Dakota, population 120,000) and Rapid City (second-largest
city in South Dakota, population 68,000) follows I-29 and I-90, while
the shortest follows I-94 for a ways, then cuts cross-country on a mix
of minor state highways to save 70 miles while taking about five minutes
longer (on a total trip time of 470 minutes).

Which one is the "best"?  If it's the fast route, there's no issue:
both roads are already "highway=motorway".

If it's the short route, how should it be classified?  Fargo and Rapid
City are both larger than any city within 200 miles, which would
seem to make them "large/important", but even by western American
standards, they're pretty small in an absolute sense.  Trunk, primary,
or secondary?

-- 
Mark

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

[Talk-de] Dt. Kartenstil: Rendern von historic=fort

[Sven Geggus]

Hallo zusammen,

OSM carto rendert seit der aktuellen Version für den tag historic=fort
folgendes Symbol:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbols/fort.svg

Aus meiner Sicht sieht das irgendwie aus wie eine Spielzeugburg von
Playmobil oder so.

Im deutschen kartenstil rendere ich seit jeher die in deutschen karten
üblichen Symbole für Burgen und Schlösser:
https://github.com/giggls/openstreetmap-carto-de/blob/master/symbols-de/atkis/burg.svg
https://github.com/giggls/openstreetmap-carto-de/blob/master/symbols-de/atkis/burgruine.svg

Nun frage ich mich wie man mit historic=fort umgehen sollte.

Die Playmobil Burg gefällt mir nicht.

Ich tendiere dazu für historic=fort einfach auch das Burgsymbol zu
verwenden.

Was denkt ihr?

Sven

-- 
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-cz] telefoni budky

[Petr Vozdecký]

...že ty máš svrbění založit na taskmanovi další projekt... :)
-- Původní e-mail --
Od: Miroslav Suchý 
Komu: OpenStreetMap Czech Republic 
Datum: 15. 2. 2018 22:32:51
Předmět: [Talk-cz] telefoni budky
"Tak jsem si v posledni dobe vsimnul, ze se zacinaji mnozit vyrabovane
telefoni budky. Resp. profesionalne odmontovany vnitrek. A je toho
tolik, ze to vypada na dalsi vlnu ruseni telefonich budek.
Just saying.

Mirek

___
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] Highway=trunk : harmonization between countries ?

[djakk djakk]

We could start with Brasil, France, UK, and Czechia.
But in France and in Brasil the trunk definition is not set yet ...


I've started to use a new tag in Brittany : traffic ;
low-intermediate-heavy-trunk, to show the amount of vehicles per day.
Probably that in combination of other tags (lanes, surface, width) it could
replace the highway tag.

It is probably easier to make new tags than changing old tags :)


djakk

Le ven. 23 févr. 2018 à 20:44, Matej Lieskovský 
a écrit :

> Could we perhaps start a wiki page to collect information on how every
> country classifies roads? Something like
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence but
> intended for the global community instead of the local mappers? More detail
> and less non-english text.
>
> On 23 February 2018 at 20:11, Fernando Trebien  > wrote:
>
>> I'm glad it is not so much of a problem in Czechia and I hope it would
>
> rarely be a problem anywhere.
>>
>> In any case, the idea can be developed further. Matej raises some
>> interesting points that can account for better classification. For
>> example, we could add some bias towards regional and/or national
>> routes, in order to avoid shortcuts (though not forbid them completely
>> if they are significant); likewise, we could add some bias to
>> infrastructure, such as pavement quality, signage quality, feasibility
>> for large vehicles (such as trucks), etc.
>>
>> Most interesting I think is to share with the global community how the
>> local community understands classification. Are access rights really
>> important to the map user, or is it only important to mappers? If so,
>> why can't the renderer parse access tags to decide how to represent
>> the way? (I believe that was the intention when motorroad=* was
>> proposed.)
>>
>> On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk 
>> wrote:
>> > Don’t worry, when the official system is good, lik in Czechia, it
>> matches
>> > Fernando’s suggestion :)
>> >
>> > djakk
>> >
>> >
>> > Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský <
>> lieskovsky.ma...@gmail.com>
>> > a écrit :
>> >>
>> >> Don't get me wrong, this system might work well for countries without
>> an
>> >> official system, but what do you expect to happen in the EU?
>> >> Will we have "highway=primary" + "class=tertiary" because some random
>> road
>> >> happens to be a shortcut? Or do you expect us in Czechia to use
>> "class=II"
>> >> while germans use "class=S" so that it actually matches the signage?
>> Will
>> >> the renderer parse ref numbers (and ignore the main tag) or will we
>> receive
>> >> hundreds of complaints about some section of the road having (what
>> every
>> >> local resident will consider to be) the wrong class?
>> >>
>> >> How do you determine "important cities" when even the line between
>> towns
>> >> and cities is country-dependant? Or is using administrative
>> differences only
>> >> not OK for roads?
>> >>
>> >> Even Waze actually follows local administration.
>> >>
>> >>
>> >> Long story short: I am strongly against deploying this system in
>> countries
>> >> with a functioning official classification system.
>> >>
>> >> On 23 February 2018 at 18:06, Fernando Trebien
>> >>  wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> Administrative classification is not strictly related everywhere to
>> >>> signage, structure and access rights.
>> >>>
>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
>> >>> wrote:
>> >>> > I know that « trunk »  is country-dependent but why not moving it
>> to a
>> >>> > worldwide definition ? Administrative classification could be moved
>> to
>> >>> > other
>> >>> > tags :)
>> >>> >
>> >>> >
>> >>> > djakk
>> >>> >
>> >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
>> >>> > 
>> >>> > a écrit :
>> >>> >>
>> >>> >> Greetings
>> >>> >> I'd like to caution against using this system globally. In Czechia,
>> >>> >> roads
>> >>> >> are formally classified into classes, which influence signage, ref
>> >>> >> numbers
>> >>> >> and so on. Deploying this system here would make the tag
>> >>> >> confusing/useless
>> >>> >> and would likely face enormous backlash. I have no problems with
>> using
>> >>> >> this
>> >>> >> system in countries without a clearly defined road classification,
>> but
>> >>> >> please don't touch the countries where there is no doubt about what
>> >>> >> class
>> >>> >> any given road is.
>> >>> >> Happy mapping!
>> >>> >>
>> >>> >> On 22 February 2018 at 16:20, djakk djakk 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Hello,
>> >>> >>>
>> >>> >>> I totally agree with you, the definition you provide,
>> >>> >>> administrative-free, tends to the same osm map between countries.
>> >>> >>>
>> >>> >>> djakk
>> >>> >>>
>> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>> >>> >>>  a écrit :
>> 

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

Dne 23.2.2018 v 20:05 majka napsal(a):
> Jo, podařilo se mi při jedné akci místo kopírování tagů kopírovat
> celou schránku, a byla jsem při tom hezky rozjetá. Místo ctrl+shift+v
> se mi dařilo jen ctrl+v, a v JOSM je to hned. 
>
> Nejzákeřnější na tom je, že některé byly naprosto přesně v zákrytu,
> takže opticky to vidět nebylo a přitom žádné varování nepřišlo.
>
> Budu o víkendu procházet ten zbytek, už teď je toho dost sloučeného.
>
> Majka

:-D

Poslední věc dneska - vyhodil jsou křováka (stejně to k ničemu není) a
místo toho přidal zobrazení vzdálenosti mezi poštou a OSM. Nad 250m se
vzdálenost zobrazí červeně:



Výhledově bych chtěl přidat možnost zobrazit si ty dva body najednou na
mapě a mezi nimi natáhnout spojnici. Ale na to je nejprve potřeba přidat
podporu na openstreetmap.cz.

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

Could we perhaps start a wiki page to collect information on how every
country classifies roads? Something like
https://wiki.openstreetmap.org/wiki/Highway:International_equivalence but
intended for the global community instead of the local mappers? More detail
and less non-english text.

On 23 February 2018 at 20:11, Fernando Trebien 
wrote:

> I'm glad it is not so much of a problem in Czechia and I hope it would
> rarely be a problem anywhere.
>
> In any case, the idea can be developed further. Matej raises some
> interesting points that can account for better classification. For
> example, we could add some bias towards regional and/or national
> routes, in order to avoid shortcuts (though not forbid them completely
> if they are significant); likewise, we could add some bias to
> infrastructure, such as pavement quality, signage quality, feasibility
> for large vehicles (such as trucks), etc.
>
> Most interesting I think is to share with the global community how the
> local community understands classification. Are access rights really
> important to the map user, or is it only important to mappers? If so,
> why can't the renderer parse access tags to decide how to represent
> the way? (I believe that was the intention when motorroad=* was
> proposed.)
>
> On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk 
> wrote:
> > Don’t worry, when the official system is good, lik in Czechia, it matches
> > Fernando’s suggestion :)
> >
> > djakk
> >
> >
> > Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský <
> lieskovsky.ma...@gmail.com>
> > a écrit :
> >>
> >> Don't get me wrong, this system might work well for countries without an
> >> official system, but what do you expect to happen in the EU?
> >> Will we have "highway=primary" + "class=tertiary" because some random
> road
> >> happens to be a shortcut? Or do you expect us in Czechia to use
> "class=II"
> >> while germans use "class=S" so that it actually matches the signage?
> Will
> >> the renderer parse ref numbers (and ignore the main tag) or will we
> receive
> >> hundreds of complaints about some section of the road having (what every
> >> local resident will consider to be) the wrong class?
> >>
> >> How do you determine "important cities" when even the line between towns
> >> and cities is country-dependant? Or is using administrative differences
> only
> >> not OK for roads?
> >>
> >> Even Waze actually follows local administration.
> >>
> >>
> >> Long story short: I am strongly against deploying this system in
> countries
> >> with a functioning official classification system.
> >>
> >> On 23 February 2018 at 18:06, Fernando Trebien
> >>  wrote:
> >>>
> >>> +1
> >>>
> >>> Administrative classification is not strictly related everywhere to
> >>> signage, structure and access rights.
> >>>
> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
> >>> wrote:
> >>> > I know that « trunk »  is country-dependent but why not moving it to
> a
> >>> > worldwide definition ? Administrative classification could be moved
> to
> >>> > other
> >>> > tags :)
> >>> >
> >>> >
> >>> > djakk
> >>> >
> >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
> >>> > 
> >>> > a écrit :
> >>> >>
> >>> >> Greetings
> >>> >> I'd like to caution against using this system globally. In Czechia,
> >>> >> roads
> >>> >> are formally classified into classes, which influence signage, ref
> >>> >> numbers
> >>> >> and so on. Deploying this system here would make the tag
> >>> >> confusing/useless
> >>> >> and would likely face enormous backlash. I have no problems with
> using
> >>> >> this
> >>> >> system in countries without a clearly defined road classification,
> but
> >>> >> please don't touch the countries where there is no doubt about what
> >>> >> class
> >>> >> any given road is.
> >>> >> Happy mapping!
> >>> >>
> >>> >> On 22 February 2018 at 16:20, djakk djakk 
> >>> >> wrote:
> >>> >>>
> >>> >>> Hello,
> >>> >>>
> >>> >>> I totally agree with you, the definition you provide,
> >>> >>> administrative-free, tends to the same osm map between countries.
> >>> >>>
> >>> >>> djakk
> >>> >>>
> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
> >>> >>>  a écrit :
> >>> 
> >>>  Landing on this discussion several months late. I've just heard of
> >>>  it
> >>>  by reading a wiki talk page [1].
> >>> 
> >>>  Since 13 February 2009, the wiki [2] criticises highway
> >>>  classification
> >>>  as problematic/unverifiable. This has also been subject to a lot
> of
> >>>  controversy (and edit wars) in my local community (Brazil),
> >>>  especially
> >>>  regarding the effect of (lack of) pavement.
> >>> 
> >>>  In trying to achieve greater consensus some years ago, I decided
> to
> >>>  seek opinions elsewhere and finally I arrived at this scheme [3]
> >>> 

Re: [Talk-es] Carretera sin línea central

[yo paseopor]

las carreteras sin líneas a efectos prácticos quedan convertidas en
carreteras de un solo carril, de doble sentido. Así que , según mi criterio
sería:
highway=unclassified (o tertiary o secondary  - según la referencia y
categoría que le dé la administración a la que compete -aunque ya sabeis
que no estoy de acuerdo con ello en todos los casos-)
lanes=1
oneway=no

Salut i mapes
yopaseopor

2018-02-23 18:09 GMT+01:00 Javier Sánchez Portero :

> Si pones lanes=1 implica oneway=yes. Es una carretera de doble sentido.
>
> El 23 de febrero de 2018, 17:00, Jorge Sanz Sanfructuoso <
> sanc...@gmail.com> escribió:
>
>> Yo esas las pongo como lanes=1, no hace falta poner oneway=no . Ya indica
>> lo que es con eso.
>>
>> El vie., 23 feb. 2018 a las 17:55, Javier Sánchez Portero (<
>> javiers...@gmail.com>) escribió:
>>
>>> Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se
>>> cual sería el término adecuado en inglés.
>>>
>>> El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega <
>>> i...@sanchezortega.es> escribió:
>>>
 On 2018-02-23 14:51, Javier Sánchez Portero wrote:

> Hola
>
> Hay sitios rurales en los que las carreteras no tienen pintada línea
> central. Pueden ser unclassified, tertiary o incluso secondary. Por
> supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
> etiqueta para indicarlo? El método más heavy sería lanes=1
> oneway=no, pero me resulta.
>

 Creo que se trata de carreteras de dos carriles (uno por sentido), sin
 separación por marcas viales.

 Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:

 En las calzadas con doble sentido de circulación y dos carriles,
> SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.
>

 Es decir, es perfectamente posible una carretera con calzada de doble
 sentido y un carril para cada sentido de la circulación, aun cuando no haya
 señales horizontales (línea pintada) que los separen.


 [1] http://www.dgt.es/es/seguridad-vial/normativa-y-legislacion/
 reglamento-trafico/circulacion-general/normas-basicas/

 --
 Iván Sánchez Ortega 

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

>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>> --
>> Jorge Sanz Sanfructuoso - Sanchi
>> Blog http://jorgesanz.es/
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

I'm glad it is not so much of a problem in Czechia and I hope it would
rarely be a problem anywhere.

In any case, the idea can be developed further. Matej raises some
interesting points that can account for better classification. For
example, we could add some bias towards regional and/or national
routes, in order to avoid shortcuts (though not forbid them completely
if they are significant); likewise, we could add some bias to
infrastructure, such as pavement quality, signage quality, feasibility
for large vehicles (such as trucks), etc.

Most interesting I think is to share with the global community how the
local community understands classification. Are access rights really
important to the map user, or is it only important to mappers? If so,
why can't the renderer parse access tags to decide how to represent
the way? (I believe that was the intention when motorroad=* was
proposed.)

On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk  wrote:
> Don’t worry, when the official system is good, lik in Czechia, it matches
> Fernando’s suggestion :)
>
> djakk
>
>
> Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský 
> a écrit :
>>
>> Don't get me wrong, this system might work well for countries without an
>> official system, but what do you expect to happen in the EU?
>> Will we have "highway=primary" + "class=tertiary" because some random road
>> happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
>> while germans use "class=S" so that it actually matches the signage? Will
>> the renderer parse ref numbers (and ignore the main tag) or will we receive
>> hundreds of complaints about some section of the road having (what every
>> local resident will consider to be) the wrong class?
>>
>> How do you determine "important cities" when even the line between towns
>> and cities is country-dependant? Or is using administrative differences only
>> not OK for roads?
>>
>> Even Waze actually follows local administration.
>>
>>
>> Long story short: I am strongly against deploying this system in countries
>> with a functioning official classification system.
>>
>> On 23 February 2018 at 18:06, Fernando Trebien
>>  wrote:
>>>
>>> +1
>>>
>>> Administrative classification is not strictly related everywhere to
>>> signage, structure and access rights.
>>>
>>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
>>> wrote:
>>> > I know that « trunk »  is country-dependent but why not moving it to a
>>> > worldwide definition ? Administrative classification could be moved to
>>> > other
>>> > tags :)
>>> >
>>> >
>>> > djakk
>>> >
>>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
>>> > 
>>> > a écrit :
>>> >>
>>> >> Greetings
>>> >> I'd like to caution against using this system globally. In Czechia,
>>> >> roads
>>> >> are formally classified into classes, which influence signage, ref
>>> >> numbers
>>> >> and so on. Deploying this system here would make the tag
>>> >> confusing/useless
>>> >> and would likely face enormous backlash. I have no problems with using
>>> >> this
>>> >> system in countries without a clearly defined road classification, but
>>> >> please don't touch the countries where there is no doubt about what
>>> >> class
>>> >> any given road is.
>>> >> Happy mapping!
>>> >>
>>> >> On 22 February 2018 at 16:20, djakk djakk 
>>> >> wrote:
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> I totally agree with you, the definition you provide,
>>> >>> administrative-free, tends to the same osm map between countries.
>>> >>>
>>> >>> djakk
>>> >>>
>>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>>> >>>  a écrit :
>>> 
>>>  Landing on this discussion several months late. I've just heard of
>>>  it
>>>  by reading a wiki talk page [1].
>>> 
>>>  Since 13 February 2009, the wiki [2] criticises highway
>>>  classification
>>>  as problematic/unverifiable. This has also been subject to a lot of
>>>  controversy (and edit wars) in my local community (Brazil),
>>>  especially
>>>  regarding the effect of (lack of) pavement.
>>> 
>>>  In trying to achieve greater consensus some years ago, I decided to
>>>  seek opinions elsewhere and finally I arrived at this scheme [3]
>>>  which
>>>  I think is very useful, if not perfect yet. It can be easily
>>>  summarised like this:
>>>  - trunk: best routes between large/important cities
>>>  - primary: best routes between cities and above
>>>  - secondary: best routes between towns/suburbs and above
>>>  - tertiary: best routes between villages/neighbourhoods and above
>>>  - unclassified: best routes between other place=* and above
>>> 
>>>  For example, the best route between two villages would be at least
>>>  tertiary. So would be the best route between a village and a town or
>>>  a
>>> 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

@djakk: I'd rather not rely on some global algorithm coming to the exact
same conclusion. Making the classification not match the algorithm
perfectly (because it forgot to look at number of lanes or traffic light
priorities or whatever) seems to me whole lot better than randomly getting
roads with classification that matches neither the signage, other maps nor
reality. We have a good local system - if it ain't broken, don't fix it.

@Fernando:
Borders are tricky - Czech roads are markedly worse than equivalent German
roads, so harmonisation by "quality" fails. Austria is far faster than us
at building better roads, so you can end up with a motorway ending at the
border because our government hasn't gotten around to actually building the
part on our side. If you convince the EU to agree on a definition of an
important city, you deserve a Nobel peace prize - so good luck classifying
by "importance".
Trunks are (at least here in Prague) either the (incomplete) inner city
circuit, the main "radial" roads that usually connect the centre with
motorways, or other random sections that would be a motorway if they met
the standard. Knowing Czech roads, you can get a reasonable estimate for
what the road is like from class alone.
I'd guess that the fragments are a result of problems with coordinating
road construction. Between states its quite obvious, but even different
regions might have a problem to coordinate perfectly and motorways tend to
get built in pieces according to how well the planning for each of them
goes.

On 23 February 2018 at 20:01, Fernando Trebien 
wrote:

> On Fri, Feb 23, 2018 at 3:31 PM, Fernando Trebien
>  wrote:
> > Assuming the map is correctly classified in Europe, I'm seeing many
> > fragments of motorways and trunks all over the map. Is this an
> > artifact of local definitions? Or is it intentional and desirable?
>
> I should note that I don't see such artifacts in England, Australia,
> South Africa, Russia, Japan, among others.
>
> > On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský
> >  wrote:
> >> Don't get me wrong, this system might work well for countries without an
> >> official system, but what do you expect to happen in the EU?
> >> Will we have "highway=primary" + "class=tertiary" because some random
> road
> >> happens to be a shortcut? Or do you expect us in Czechia to use
> "class=II"
> >> while germans use "class=S" so that it actually matches the signage?
> Will
> >> the renderer parse ref numbers (and ignore the main tag) or will we
> receive
> >> hundreds of complaints about some section of the road having (what every
> >> local resident will consider to be) the wrong class?
> >>
> >> How do you determine "important cities" when even the line between
> towns and
> >> cities is country-dependant? Or is using administrative differences
> only not
> >> OK for roads?
> >>
> >> Even Waze actually follows local administration.
> >>
> >>
> >> Long story short: I am strongly against deploying this system in
> countries
> >> with a functioning official classification system.
> >>
> >> On 23 February 2018 at 18:06, Fernando Trebien <
> fernando.treb...@gmail.com>
> >> wrote:
> >>>
> >>> +1
> >>>
> >>> Administrative classification is not strictly related everywhere to
> >>> signage, structure and access rights.
> >>>
> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
> >>> wrote:
> >>> > I know that « trunk »  is country-dependent but why not moving it to
> a
> >>> > worldwide definition ? Administrative classification could be moved
> to
> >>> > other
> >>> > tags :)
> >>> >
> >>> >
> >>> > djakk
> >>> >
> >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
> >>> > 
> >>> > a écrit :
> >>> >>
> >>> >> Greetings
> >>> >> I'd like to caution against using this system globally. In Czechia,
> >>> >> roads
> >>> >> are formally classified into classes, which influence signage, ref
> >>> >> numbers
> >>> >> and so on. Deploying this system here would make the tag
> >>> >> confusing/useless
> >>> >> and would likely face enormous backlash. I have no problems with
> using
> >>> >> this
> >>> >> system in countries without a clearly defined road classification,
> but
> >>> >> please don't touch the countries where there is no doubt about what
> >>> >> class
> >>> >> any given road is.
> >>> >> Happy mapping!
> >>> >>
> >>> >> On 22 February 2018 at 16:20, djakk djakk 
> >>> >> wrote:
> >>> >>>
> >>> >>> Hello,
> >>> >>>
> >>> >>> I totally agree with you, the definition you provide,
> >>> >>> administrative-free, tends to the same osm map between countries.
> >>> >>>
> >>> >>> djakk
> >>> >>>
> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
> >>> >>>  a écrit :
> >>> 
> >>>  Landing on this discussion several months late. I've just heard
> of it
> >>>  by reading a wiki talk page 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

On Fri, Feb 23, 2018 at 3:31 PM, Fernando Trebien
 wrote:
> Assuming the map is correctly classified in Europe, I'm seeing many
> fragments of motorways and trunks all over the map. Is this an
> artifact of local definitions? Or is it intentional and desirable?

I should note that I don't see such artifacts in England, Australia,
South Africa, Russia, Japan, among others.

> On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský
>  wrote:
>> Don't get me wrong, this system might work well for countries without an
>> official system, but what do you expect to happen in the EU?
>> Will we have "highway=primary" + "class=tertiary" because some random road
>> happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
>> while germans use "class=S" so that it actually matches the signage? Will
>> the renderer parse ref numbers (and ignore the main tag) or will we receive
>> hundreds of complaints about some section of the road having (what every
>> local resident will consider to be) the wrong class?
>>
>> How do you determine "important cities" when even the line between towns and
>> cities is country-dependant? Or is using administrative differences only not
>> OK for roads?
>>
>> Even Waze actually follows local administration.
>>
>>
>> Long story short: I am strongly against deploying this system in countries
>> with a functioning official classification system.
>>
>> On 23 February 2018 at 18:06, Fernando Trebien 
>> wrote:
>>>
>>> +1
>>>
>>> Administrative classification is not strictly related everywhere to
>>> signage, structure and access rights.
>>>
>>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
>>> wrote:
>>> > I know that « trunk »  is country-dependent but why not moving it to a
>>> > worldwide definition ? Administrative classification could be moved to
>>> > other
>>> > tags :)
>>> >
>>> >
>>> > djakk
>>> >
>>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
>>> > 
>>> > a écrit :
>>> >>
>>> >> Greetings
>>> >> I'd like to caution against using this system globally. In Czechia,
>>> >> roads
>>> >> are formally classified into classes, which influence signage, ref
>>> >> numbers
>>> >> and so on. Deploying this system here would make the tag
>>> >> confusing/useless
>>> >> and would likely face enormous backlash. I have no problems with using
>>> >> this
>>> >> system in countries without a clearly defined road classification, but
>>> >> please don't touch the countries where there is no doubt about what
>>> >> class
>>> >> any given road is.
>>> >> Happy mapping!
>>> >>
>>> >> On 22 February 2018 at 16:20, djakk djakk 
>>> >> wrote:
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> I totally agree with you, the definition you provide,
>>> >>> administrative-free, tends to the same osm map between countries.
>>> >>>
>>> >>> djakk
>>> >>>
>>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>>> >>>  a écrit :
>>> 
>>>  Landing on this discussion several months late. I've just heard of it
>>>  by reading a wiki talk page [1].
>>> 
>>>  Since 13 February 2009, the wiki [2] criticises highway
>>>  classification
>>>  as problematic/unverifiable. This has also been subject to a lot of
>>>  controversy (and edit wars) in my local community (Brazil),
>>>  especially
>>>  regarding the effect of (lack of) pavement.
>>> 
>>>  In trying to achieve greater consensus some years ago, I decided to
>>>  seek opinions elsewhere and finally I arrived at this scheme [3]
>>>  which
>>>  I think is very useful, if not perfect yet. It can be easily
>>>  summarised like this:
>>>  - trunk: best routes between large/important cities
>>>  - primary: best routes between cities and above
>>>  - secondary: best routes between towns/suburbs and above
>>>  - tertiary: best routes between villages/neighbourhoods and above
>>>  - unclassified: best routes between other place=* and above
>>> 
>>>  For example, the best route between two villages would be at least
>>>  tertiary. So would be the best route between a village and a town or
>>>  a
>>>  city. Parts of this route might have a higher class in case they are
>>>  part of a route between more important places.
>>> 
>>>  It surely raises the problem of determining optimal routes. Maybe a
>>>  sensible criterion would be average travel time without traffic
>>>  congestion. A number of vehicles may be selected for this average -
>>>  could be motorcycle+car+bus+truck, or simply car+truck.
>>> 
>>>  Early results in my area [4, in Portuguese] seem promising and have
>>>  produced more consensus than any previous proposals. To me, this
>>>  method seems to:
>>>  - resist alternations in classification along the same road
>>>  - work 

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Et attention aux autres pièges, l'extension minimale peut avoir des
concavités recouvertes totalement par l'extension maximale sans concavité
(cela se complique si l'extension minimale contient des trous enclavés,
mais l'extension maximale en supprime en les recouvrant totalement! dans ce
cas comment remplir les trous ? La triangulation simple entre les deux
polygones ne marche pas, c'est une triangulation du trou dans la concavité
de l'extension minimale qu'il faut faire en cherchant un point central.

Ceux qui cherchent un peu vont trouver des articles mathématiques traitant
de l'extrême complexité algorithmique aussi pour créer des "buffers" autour
d'un polygone si on veut un rendu correct (et notamment pour traiter les
"mitres" et respecter les tangentes, et résoudre les cas de croisements (il
faut savoir que même dans les meilleurs rendus SVG actuels, les "buffers"
calculés pour tracer les traits (strokewidth) ont des anomalies autour des
angles et en cas de croisement de buffers. Seuls des articles très récents
(dont un écrit dans une thèse d'un docteur en mathématiques chinois)
donnent les détails des algos (mais l'implémentation est couverte par des
brevets, acquis par des fabricants de cartes graphiques...)


Le 23 février 2018 à 19:29, Philippe Verdy  a écrit :

> C'est aussi une idée, mais alors les rôles normaux ("inner"/"outer") pour
> l'extension minimale, et les rôles augmentés de "_max" pour l'extension
> maximale, ce qui permet aussi à un moteur de rendu d'utiliser un
> remplissage à semi-transparence linéaire, s'il sait interpoler entre les
> deux tracés (ce qui n'est pas simple car ils n'ont pas la même forme ni le
> même nombre de noeuds; cela demande une triangulation entre les deux
> polygones puis l'interpolation linéraire dans chaque triangle...)
>
> Le 23 février 2018 à 18:05, djakk djakk  a écrit :
>
>> Noeud, ligne ou surface selon les cas (quartier de ville - fond de vallée
>> - massif montagneux).
>> Quant au polygone, quand la limite est floue, en faire un petit et un
>> grand (cœur de la region - extension maximum de la région) ?
>>
>>
>> djakk
>>
>>
>> Le ven. 23 févr. 2018 à 17:58, Philippe Verdy  a
>> écrit :
>>
>>> Je ne vois pas mettre ça dans les rôles des membres de relations, mais
>>> directement comme tags des chemins tracés... Le rôle est strictement le
>>> même ce n'est que la précision du tracé qui est floue (en fait la précision
>>> des noeuds utilisés, mais on na va pas taguer nécessairement tous les
>>> noeuds d'un chemin, d'autant plus que ce tracé peut passer ou coïncider
>>> localement à des points précis (ils le seront s'ils ont des tags utiles,
>>> non ignorés, c'est à dire non suppressibles automatiquement comme les tags
>>> d'import automatique, ainsi que certains tags purement informatifs comme
>>> "note=*" ou "source=*").
>>>
>>> Ajouter des rôles (en plus avec un nom anglo-français horrible ) ne
>>> va pas aider du tout. C'est la géométrie qui est concernée (donc au plus
>>> près du tracé de bas niveau, donc sur les noeuds, voire les chemins si ce
>>> sont de noeuds "anonymes").
>>>
>>> Le 23 février 2018 à 14:53, Jérôme Amagat  a
>>> écrit :
>>>
 Un node c'est déjà pas mal mais on perd pas mal par rapport a un
 polygone au niveau de la taille, de l’étendu.
 Pour les lieux habités place=city town village hamlet ... on a une idée
 de la taille dans le tag mais comment ont fait pour différencier par
 exemple les Alpes et un de ses massifs?

 Un truc que je trouverais pas mal c'est créer une relation multipolygon
 avec des membres qui ont des rôles du type "outer_approximatif" voir
 "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
 pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
 une cote, une crête de montagne ou au milieu de nul part.

 Les limites de la zone ne sont pas le seul problème, quel tag doit on
 utiliser?
 Il n'y a rien (ou presque) sur le wiki.
 Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
 donne la raison d’être de ce nom comme une zone liée à son relief (une
 vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.

 Deja present dans osm ont peut trouver avec taginfo :
 des chose en *=mountain_range
 des natural=plain, natural=plateau
 ...
 Pour les vallée il y a

 J'ai créé quelque "truc" il y a quelques temps :
 La Bresse : https://www.openstreetmap.org/relation/3078437
 La Dombes : https://www.openstreetmap.org/relation/3078442
 Le Jura Français (les communes en zone de montagne donc c'est du
 naturel lié a de l'administratif)


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

 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

What do you think about changes of classification at country borders?
Can this be somehow reconciled?

Assuming the map is correctly classified in Europe, I'm seeing many
fragments of motorways and trunks all over the map. Is this an
artifact of local definitions? Or is it intentional and desirable?


On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský
 wrote:
> Don't get me wrong, this system might work well for countries without an
> official system, but what do you expect to happen in the EU?
> Will we have "highway=primary" + "class=tertiary" because some random road
> happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
> while germans use "class=S" so that it actually matches the signage? Will
> the renderer parse ref numbers (and ignore the main tag) or will we receive
> hundreds of complaints about some section of the road having (what every
> local resident will consider to be) the wrong class?
>
> How do you determine "important cities" when even the line between towns and
> cities is country-dependant? Or is using administrative differences only not
> OK for roads?
>
> Even Waze actually follows local administration.
>
>
> Long story short: I am strongly against deploying this system in countries
> with a functioning official classification system.
>
> On 23 February 2018 at 18:06, Fernando Trebien 
> wrote:
>>
>> +1
>>
>> Administrative classification is not strictly related everywhere to
>> signage, structure and access rights.
>>
>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
>> wrote:
>> > I know that « trunk »  is country-dependent but why not moving it to a
>> > worldwide definition ? Administrative classification could be moved to
>> > other
>> > tags :)
>> >
>> >
>> > djakk
>> >
>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
>> > 
>> > a écrit :
>> >>
>> >> Greetings
>> >> I'd like to caution against using this system globally. In Czechia,
>> >> roads
>> >> are formally classified into classes, which influence signage, ref
>> >> numbers
>> >> and so on. Deploying this system here would make the tag
>> >> confusing/useless
>> >> and would likely face enormous backlash. I have no problems with using
>> >> this
>> >> system in countries without a clearly defined road classification, but
>> >> please don't touch the countries where there is no doubt about what
>> >> class
>> >> any given road is.
>> >> Happy mapping!
>> >>
>> >> On 22 February 2018 at 16:20, djakk djakk 
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I totally agree with you, the definition you provide,
>> >>> administrative-free, tends to the same osm map between countries.
>> >>>
>> >>> djakk
>> >>>
>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>> >>>  a écrit :
>> 
>>  Landing on this discussion several months late. I've just heard of it
>>  by reading a wiki talk page [1].
>> 
>>  Since 13 February 2009, the wiki [2] criticises highway
>>  classification
>>  as problematic/unverifiable. This has also been subject to a lot of
>>  controversy (and edit wars) in my local community (Brazil),
>>  especially
>>  regarding the effect of (lack of) pavement.
>> 
>>  In trying to achieve greater consensus some years ago, I decided to
>>  seek opinions elsewhere and finally I arrived at this scheme [3]
>>  which
>>  I think is very useful, if not perfect yet. It can be easily
>>  summarised like this:
>>  - trunk: best routes between large/important cities
>>  - primary: best routes between cities and above
>>  - secondary: best routes between towns/suburbs and above
>>  - tertiary: best routes between villages/neighbourhoods and above
>>  - unclassified: best routes between other place=* and above
>> 
>>  For example, the best route between two villages would be at least
>>  tertiary. So would be the best route between a village and a town or
>>  a
>>  city. Parts of this route might have a higher class in case they are
>>  part of a route between more important places.
>> 
>>  It surely raises the problem of determining optimal routes. Maybe a
>>  sensible criterion would be average travel time without traffic
>>  congestion. A number of vehicles may be selected for this average -
>>  could be motorcycle+car+bus+truck, or simply car+truck.
>> 
>>  Early results in my area [4, in Portuguese] seem promising and have
>>  produced more consensus than any previous proposals. To me, this
>>  method seems to:
>>  - resist alternations in classification along the same road
>>  - work across borders (where classification discontinuities are
>>  expected because each country is using different classification
>>  criteria)
>>  - account for road network topology
>>  - work in 

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

C'est aussi une idée, mais alors les rôles normaux ("inner"/"outer") pour
l'extension minimale, et les rôles augmentés de "_max" pour l'extension
maximale, ce qui permet aussi à un moteur de rendu d'utiliser un
remplissage à semi-transparence linéaire, s'il sait interpoler entre les
deux tracés (ce qui n'est pas simple car ils n'ont pas la même forme ni le
même nombre de noeuds; cela demande une triangulation entre les deux
polygones puis l'interpolation linéraire dans chaque triangle...)

Le 23 février 2018 à 18:05, djakk djakk  a écrit :

> Noeud, ligne ou surface selon les cas (quartier de ville - fond de vallée
> - massif montagneux).
> Quant au polygone, quand la limite est floue, en faire un petit et un
> grand (cœur de la region - extension maximum de la région) ?
>
>
> djakk
>
>
> Le ven. 23 févr. 2018 à 17:58, Philippe Verdy  a
> écrit :
>
>> Je ne vois pas mettre ça dans les rôles des membres de relations, mais
>> directement comme tags des chemins tracés... Le rôle est strictement le
>> même ce n'est que la précision du tracé qui est floue (en fait la précision
>> des noeuds utilisés, mais on na va pas taguer nécessairement tous les
>> noeuds d'un chemin, d'autant plus que ce tracé peut passer ou coïncider
>> localement à des points précis (ils le seront s'ils ont des tags utiles,
>> non ignorés, c'est à dire non suppressibles automatiquement comme les tags
>> d'import automatique, ainsi que certains tags purement informatifs comme
>> "note=*" ou "source=*").
>>
>> Ajouter des rôles (en plus avec un nom anglo-français horrible ) ne
>> va pas aider du tout. C'est la géométrie qui est concernée (donc au plus
>> près du tracé de bas niveau, donc sur les noeuds, voire les chemins si ce
>> sont de noeuds "anonymes").
>>
>> Le 23 février 2018 à 14:53, Jérôme Amagat  a
>> écrit :
>>
>>> Un node c'est déjà pas mal mais on perd pas mal par rapport a un
>>> polygone au niveau de la taille, de l’étendu.
>>> Pour les lieux habités place=city town village hamlet ... on a une idée
>>> de la taille dans le tag mais comment ont fait pour différencier par
>>> exemple les Alpes et un de ses massifs?
>>>
>>> Un truc que je trouverais pas mal c'est créer une relation multipolygon
>>> avec des membres qui ont des rôles du type "outer_approximatif" voir
>>> "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
>>> pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
>>> une cote, une crête de montagne ou au milieu de nul part.
>>>
>>> Les limites de la zone ne sont pas le seul problème, quel tag doit on
>>> utiliser?
>>> Il n'y a rien (ou presque) sur le wiki.
>>> Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
>>> donne la raison d’être de ce nom comme une zone liée à son relief (une
>>> vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.
>>>
>>> Deja present dans osm ont peut trouver avec taginfo :
>>> des chose en *=mountain_range
>>> des natural=plain, natural=plateau
>>> ...
>>> Pour les vallée il y a
>>>
>>> J'ai créé quelque "truc" il y a quelques temps :
>>> La Bresse : https://www.openstreetmap.org/relation/3078437
>>> La Dombes : https://www.openstreetmap.org/relation/3078442
>>> Le Jura Français (les communes en zone de montagne donc c'est du naturel
>>> lié a de l'administratif)
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Don’t worry, when the official system is good, lik in Czechia, it matches
Fernando’s suggestion :)

djakk


Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský 
a écrit :

> Don't get me wrong, this system might work well for countries without an
> official system, but what do you expect to happen in the EU?
> Will we have "highway=primary" + "class=tertiary" because some random road
> happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
> while germans use "class=S" so that it actually matches the signage? Will
> the renderer parse ref numbers (and ignore the main tag) or will we receive
> hundreds of complaints about some section of the road having (what every
> local resident will consider to be) the wrong class?
>
> How do you determine "important cities" when even the line between towns
> and cities is country-dependant? Or is using administrative differences
> only not OK for roads?
>
> Even Waze actually follows local administration.
>
>
> Long story short: I am strongly against deploying this system in countries
> with a functioning official classification system.
>
> On 23 February 2018 at 18:06, Fernando Trebien  > wrote:
>
>> +1
>>
>> Administrative classification is not strictly related everywhere to
>> signage, structure and access rights.
>>
>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
>> wrote:
>> > I know that « trunk »  is country-dependent but why not moving it to a
>> > worldwide definition ? Administrative classification could be moved to
>> other
>> > tags :)
>> >
>> >
>> > djakk
>> >
>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <
>> lieskovsky.ma...@gmail.com>
>> > a écrit :
>> >>
>> >> Greetings
>> >> I'd like to caution against using this system globally. In Czechia,
>> roads
>> >> are formally classified into classes, which influence signage, ref
>> numbers
>> >> and so on. Deploying this system here would make the tag
>> confusing/useless
>> >> and would likely face enormous backlash. I have no problems with using
>> this
>> >> system in countries without a clearly defined road classification, but
>> >> please don't touch the countries where there is no doubt about what
>> class
>> >> any given road is.
>> >> Happy mapping!
>> >>
>> >> On 22 February 2018 at 16:20, djakk djakk 
>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I totally agree with you, the definition you provide,
>> >>> administrative-free, tends to the same osm map between countries.
>> >>>
>> >>> djakk
>> >>>
>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>> >>>  a écrit :
>> 
>>  Landing on this discussion several months late. I've just heard of it
>>  by reading a wiki talk page [1].
>> 
>>  Since 13 February 2009, the wiki [2] criticises highway
>> classification
>>  as problematic/unverifiable. This has also been subject to a lot of
>>  controversy (and edit wars) in my local community (Brazil),
>> especially
>>  regarding the effect of (lack of) pavement.
>> 
>>  In trying to achieve greater consensus some years ago, I decided to
>>  seek opinions elsewhere and finally I arrived at this scheme [3]
>> which
>>  I think is very useful, if not perfect yet. It can be easily
>>  summarised like this:
>>  - trunk: best routes between large/important cities
>>  - primary: best routes between cities and above
>>  - secondary: best routes between towns/suburbs and above
>>  - tertiary: best routes between villages/neighbourhoods and above
>>  - unclassified: best routes between other place=* and above
>> 
>>  For example, the best route between two villages would be at least
>>  tertiary. So would be the best route between a village and a town or
>> a
>>  city. Parts of this route might have a higher class in case they are
>>  part of a route between more important places.
>> 
>>  It surely raises the problem of determining optimal routes. Maybe a
>>  sensible criterion would be average travel time without traffic
>>  congestion. A number of vehicles may be selected for this average -
>>  could be motorcycle+car+bus+truck, or simply car+truck.
>> 
>>  Early results in my area [4, in Portuguese] seem promising and have
>>  produced more consensus than any previous proposals. To me, this
>>  method seems to:
>>  - resist alternations in classification along the same road
>>  - work across borders (where classification discontinuities are
>>  expected because each country is using different classification
>>  criteria)
>>  - account for road network topology
>>  - work in countries with mostly precarious/unpaved roads or
>>  without/unknown official highway classes
>>  - work between settlements as well as within settlements
>> 
>>  Borderline cases are probably inescapable in any system that 

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

1) I'd have far fewer problems with "highway=primary" being replaced by
"highway=road" "road_class=primary" or something like that (making it
easier to say "we don't classify roads here").
2) I'm not going around telling Brazilians which Brazilian roads they're
allowed to tag as primary. I'd welcome if this was reciprocated.
3) Since when is "harmonisation" a code-word for "we don't have motorways
so neither should you"?

On 23 February 2018 at 18:56, Pierre Béland  wrote:

> If we talk of harmonization, we have to look outside of Europe and the
> major industrialized countries. The highway classsification based on
> infrastructures such as motorways and trunk roads is not adapted to the
> majority of the countries or regions.
>
> In countries or vast regions with no motorway, should we consider primary
> roads the same level as motorways? Or classify as trunk for the renderer?
>
>
> Pierre
>
>
> Le vendredi 23 février 2018 11:16:45 HNE, djakk djakk <
> djakk.dj...@gmail.com> a écrit :
>
>
> I know that « trunk »  is country-dependent but why not moving it to a
> worldwide definition ? Administrative classification could be moved to
> other tags :)
>
>
> djakk
>
> Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <
> lieskovsky.ma...@gmail.com> a écrit :
>
> Greetings
> I'd like to caution against using this system globally. In Czechia, roads
> are formally classified into classes, which influence signage, ref numbers
> and so on. Deploying this system here would make the tag confusing/useless
> and would likely face enormous backlash. I have no problems with using this
> system in countries without a clearly defined road classification, but
> please don't touch the countries where there is no doubt about what class
> any given road is.
> Happy mapping!
>
> On 22 February 2018 at 16:20, djakk djakk  wrote:
>
> Hello,
>
> I totally agree with you, the definition you provide, administrative-free,
> tends to the same osm map between countries.
>
> djakk
>
> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien <
> fernando.treb...@gmail.com> a écrit :
>
> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
>
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
>
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above
>
> For example, the best route between two villages would be at least
> tertiary. So would be the best route between a village and a town or a
> city. Parts of this route might have a higher class in case they are
> part of a route between more important places.
>
> It surely raises the problem of determining optimal routes. Maybe a
> sensible criterion would be average travel time without traffic
> congestion. A number of vehicles may be selected for this average -
> could be motorcycle+car+bus+truck, or simply car+truck.
>
> Early results in my area [4, in Portuguese] seem promising and have
> produced more consensus than any previous proposals. To me, this
> method seems to:
> - resist alternations in classification along the same road
> - work across borders (where classification discontinuities are
> expected because each country is using different classification
> criteria)
> - account for road network topology
> - work in countries with mostly precarious/unpaved roads or
> without/unknown official highway classes
> - work between settlements as well as within settlements
>
> Borderline cases are probably inescapable in any system that does not
> use solely criteria that are directly verifiable - from the ground, or
> from the law. Maybe, in certain developed countries, the system is so
> well organized that merely checking signs/laws is sufficient. That
> does not mean it is like that everywhere on the planet.
>
> OSM has so far received a lot of input from communities in developed
> countries (mostly Europe, North America and Australia) and hasn't
> given much attention to less developed/organized countries. What comes
> closest to this is what the HOT Team does, but the judgment of road
> classification one can do from satellite images in a foreign country
> is much more limited than the criteria that have been raised in this
> thread so far.
>
> I wouldn't endorse tags such as maxspeed:practical due to lack of
> verifiability (it should 

Re: [Talk-es] Calles muy estrechas

[dcapillae]

Hola, José Luis.

No estoy del todo de acuerdo, pero al menos es un criterio. Lo fundamental
es seguir algún criterio y, si puede ser, que todos sigamos el mismo.

No estoy de acuerdo en que el ancho sea subjetivo (o poco significativo)
para el caso que nos ocupa, determinar que etiqueta usar, si
«highway=pedestrian» o «highway=footway».

Mi resistencia a usar «highway=pedestrian» y «highway=residential» en calles
estrechas procede de la documentación de estas etiquetas en el wiki. Ni la
descripción de una «highway=pedestrian» [1] ni la descripción de una
«highway=residential» [2] se ajustan al tipo de calles estrechas de las que
estamos hablando.

Si alguien todavía tiene dudas, puede echarle un vistazo a esta pregunta en
el foro de ayuda [3]. En la respuesta, el autor (Andrew Chadwick) explica
que las «highway=pedestrian» son generalmente anchas, aproximadamente del
ancho de una calle residencial normal o más ancha, con espacio suficiente
para que una multitud se mueva, mientras que las «highway=footway»
generalmente son estrechas, con tal vez espacio suficiente para que pasen
dos personas o todavía más estrechas. También se explica que el nombre no es
relevante, que tanto las «highway=pedestrian» como las «highway=footway»
pueden tener nombres reconocidos oficialmente (el autor pone el ejemplo de
una «highway=footway» con nombre, aunque la cita como «highway=pedestrian»,
entiendo que por error).

En definitiva, que no está tan claro que no se pueda usar «highway=footway»
para mapear una calle estrecha en el casco urbano de un pueblo o de una
ciudad. Diría que incluso puede que sea lo más correcto.

[1] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=pedestrian
[2] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=residential
[3] https://help.openstreetmap.org/questions/2750/pedestrian-vs-footway



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

ad konference:

- odgeekovat - ja si kupodivu nemyslim, ze to je zageekovane... kdyz je ale
uzivatel komunikacni introvert, nic s tim neudelas...

- konference - probirali jsme se Zby.cz dve nove features, ktere by z noveho
rozhrani talk-cz na openstreetmap.cz udelali neco, co se vice podoba
prndacimu foru - pujde regovat primo z toho rozhrani a bude mozne zvyraznit
jen "neprectene" (=nove) zpravy. Tim se snad tato komunikacni platforma vice
zlidsti...

-- Původní zpráva --
Od: Marián Kyral
Datum: 23. 2. 2018 v 16:17:04
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )


-- Původní e-mail --
Od: Petr Vozdecký 
Komu: OpenStreetMap Czech Republic 
Datum: 23. 2. 2018 14:52:47
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )
"Překvapivě mi prakticky všichni (které jsem z Talk-cz neznal) řekli, že
Talk-cz aktivně sledují, jen do něj nepřispívají, protože se domnívají, že
ti, co do něj píšou, jsou geekové a oni by si připadali se svými dotazy
blbě. OSM komunita je totiž tvořena daleko více než jiné průměrné skupiny
lidí jedinci spíše uzavřenými - no a těm je potřeba jít spíše naproti... :)
"



A máš nějaký nápad, jak tuto konferenci odgeekovat? České diskuzní fórum na
osm.org sice funguje, ale moc se nepoužívá. Převést na jinou platformu? Nebo
jen napojit, s tím, že by mail konference fungovala dále, ale bylo by možné
diskutovat i jinak než přes email.





Jako jednu z nevýhod mail konference vidím to, že nově příchozí nemůže
přispět do nějaké starší, již neaktivní, diskuse. Možná kdyby @zby_cz
doplnil tuto funkcionalitu na https://openstreetmap.cz/talkcz





Marián

BTW: co uděláme s tagem kct_barva? Na OpenAltu jsme se shodli, že tag již
není potřeba, ale zatím se nepodařilo změnu uvést v život. Tedy projít,
doplnit, opravit původní návrh, projít wiki, zjistit co bude potřeba opravit
- třeba kčt preset v JOSM.

Marián


___ Talk-cz mailing list Talk-
c...@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] Highway=trunk : harmonization between countries ?

[Pierre Béland]

If we talk of harmonization, we have to look outside of Europe and the major 
industrialized countries. The highway classsification based on infrastructures 
such as motorways and trunk roads is not adapted to the majority of the 
countries or regions. 
In countries or vast regions with no motorway, should we consider primary roads 
the same level as motorways? Or classify as trunk for the renderer?

 
Pierre 
 

Le vendredi 23 février 2018 11:16:45 HNE, djakk djakk 
 a écrit :  
 
 I know that « trunk »  is country-dependent but why not moving it to a 
worldwide definition ? Administrative classification could be moved to other 
tags :)

djakk
Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský  a 
écrit :

Greetings
I'd like to caution against using this system globally. In Czechia, roads are 
formally classified into classes, which influence signage, ref numbers and so 
on. Deploying this system here would make the tag confusing/useless and would 
likely face enormous backlash. I have no problems with using this system in 
countries without a clearly defined road classification, but please don't touch 
the countries where there is no doubt about what class any given road is.Happy 
mapping!
On 22 February 2018 at 16:20, djakk djakk  wrote:

Hello, 
I totally agree with you, the definition you provide, administrative-free, 
tends to the same osm map between countries.  
djakk
Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien  a 
écrit :

Landing on this discussion several months late. I've just heard of it
by reading a wiki talk page [1].

Since 13 February 2009, the wiki [2] criticises highway classification
as problematic/unverifiable. This has also been subject to a lot of
controversy (and edit wars) in my local community (Brazil), especially
regarding the effect of (lack of) pavement.

In trying to achieve greater consensus some years ago, I decided to
seek opinions elsewhere and finally I arrived at this scheme [3] which
I think is very useful, if not perfect yet. It can be easily
summarised like this:
- trunk: best routes between large/important cities
- primary: best routes between cities and above
- secondary: best routes between towns/suburbs and above
- tertiary: best routes between villages/neighbourhoods and above
- unclassified: best routes between other place=* and above

For example, the best route between two villages would be at least
tertiary. So would be the best route between a village and a town or a
city. Parts of this route might have a higher class in case they are
part of a route between more important places.

It surely raises the problem of determining optimal routes. Maybe a
sensible criterion would be average travel time without traffic
congestion. A number of vehicles may be selected for this average -
could be motorcycle+car+bus+truck, or simply car+truck.

Early results in my area [4, in Portuguese] seem promising and have
produced more consensus than any previous proposals. To me, this
method seems to:
- resist alternations in classification along the same road
- work across borders (where classification discontinuities are
expected because each country is using different classification
criteria)
- account for road network topology
- work in countries with mostly precarious/unpaved roads or
without/unknown official highway classes
- work between settlements as well as within settlements

Borderline cases are probably inescapable in any system that does not
use solely criteria that are directly verifiable - from the ground, or
from the law. Maybe, in certain developed countries, the system is so
well organized that merely checking signs/laws is sufficient. That
does not mean it is like that everywhere on the planet.

OSM has so far received a lot of input from communities in developed
countries (mostly Europe, North America and Australia) and hasn't
given much attention to less developed/organized countries. What comes
closest to this is what the HOT Team does, but the judgment of road
classification one can do from satellite images in a foreign country
is much more limited than the criteria that have been raised in this
thread so far.

I wouldn't endorse tags such as maxspeed:practical due to lack of
verifiability (it should be obvious that different types of vehicles
would achieve different practical speeds). It is better to use the
legal speed in maxspeed=* and describe the practical reason for a
lower speed using surface=*, smoothness=*, and, who knows, maybe the
not yet approved hazard=* [5] (though that is intended for signed
hazards, not subjective/opinionated hazards).

For the sake of long-term sanity, I also wouldn't mix the purpose of
one tag with the purpose of other tags. To describe the surface, there
is surface=*, smoothness=* and tracktype=*. To describe access rights,
there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
describe legal speed, 

Re: [OSM-talk] OSM and Gender

[Kate Chapman]

Hi All,

The first discussion will take place Monday at 17:00 London time(1). This
will take place on the HOT Mumble server(2).

Thanks,

-Kate

(1)
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+and+Gender+First+Discussion=20180226T17=136=1
(2) https://wiki.openstreetmap.org/wiki/Mumble

On Mon, Feb 19, 2018 at 9:50 AM, Heather Leson 
wrote:

> Hello,
>
> We are hosting an online discussion about Gender and OSM. See details in
> my diary note as well as the doodle for scheduling. Add your availability
> by Thursday of this week so that we can announce the times.
>
> http://www.openstreetmap.org/user/Heather%20Leson/diary/43345
>
> We will host a few conversations on this topic. This is the first
> scheduled one. It will be hosted on mumble.
>
> Thanks
>
> Heather Leson and Kate Chapman
>
> Heather Leson
> heatherle...@gmail.com
> Twitter/skype: HeatherLeson
> Blog: textontechs.com
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Matej Lieskovský]

Don't get me wrong, this system might work well for countries without an
official system, but what do you expect to happen in the EU?
Will we have "highway=primary" + "class=tertiary" because some random road
happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
while germans use "class=S" so that it actually matches the signage? Will
the renderer parse ref numbers (and ignore the main tag) or will we receive
hundreds of complaints about some section of the road having (what every
local resident will consider to be) the wrong class?

How do you determine "important cities" when even the line between towns
and cities is country-dependant? Or is using administrative differences
only not OK for roads?

Even Waze actually follows local administration.


Long story short: I am strongly against deploying this system in countries
with a functioning official classification system.

On 23 February 2018 at 18:06, Fernando Trebien 
wrote:

> +1
>
> Administrative classification is not strictly related everywhere to
> signage, structure and access rights.
>
> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk 
> wrote:
> > I know that « trunk »  is country-dependent but why not moving it to a
> > worldwide definition ? Administrative classification could be moved to
> other
> > tags :)
> >
> >
> > djakk
> >
> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <
> lieskovsky.ma...@gmail.com>
> > a écrit :
> >>
> >> Greetings
> >> I'd like to caution against using this system globally. In Czechia,
> roads
> >> are formally classified into classes, which influence signage, ref
> numbers
> >> and so on. Deploying this system here would make the tag
> confusing/useless
> >> and would likely face enormous backlash. I have no problems with using
> this
> >> system in countries without a clearly defined road classification, but
> >> please don't touch the countries where there is no doubt about what
> class
> >> any given road is.
> >> Happy mapping!
> >>
> >> On 22 February 2018 at 16:20, djakk djakk 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I totally agree with you, the definition you provide,
> >>> administrative-free, tends to the same osm map between countries.
> >>>
> >>> djakk
> >>>
> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
> >>>  a écrit :
> 
>  Landing on this discussion several months late. I've just heard of it
>  by reading a wiki talk page [1].
> 
>  Since 13 February 2009, the wiki [2] criticises highway classification
>  as problematic/unverifiable. This has also been subject to a lot of
>  controversy (and edit wars) in my local community (Brazil), especially
>  regarding the effect of (lack of) pavement.
> 
>  In trying to achieve greater consensus some years ago, I decided to
>  seek opinions elsewhere and finally I arrived at this scheme [3] which
>  I think is very useful, if not perfect yet. It can be easily
>  summarised like this:
>  - trunk: best routes between large/important cities
>  - primary: best routes between cities and above
>  - secondary: best routes between towns/suburbs and above
>  - tertiary: best routes between villages/neighbourhoods and above
>  - unclassified: best routes between other place=* and above
> 
>  For example, the best route between two villages would be at least
>  tertiary. So would be the best route between a village and a town or a
>  city. Parts of this route might have a higher class in case they are
>  part of a route between more important places.
> 
>  It surely raises the problem of determining optimal routes. Maybe a
>  sensible criterion would be average travel time without traffic
>  congestion. A number of vehicles may be selected for this average -
>  could be motorcycle+car+bus+truck, or simply car+truck.
> 
>  Early results in my area [4, in Portuguese] seem promising and have
>  produced more consensus than any previous proposals. To me, this
>  method seems to:
>  - resist alternations in classification along the same road
>  - work across borders (where classification discontinuities are
>  expected because each country is using different classification
>  criteria)
>  - account for road network topology
>  - work in countries with mostly precarious/unpaved roads or
>  without/unknown official highway classes
>  - work between settlements as well as within settlements
> 
>  Borderline cases are probably inescapable in any system that does not
>  use solely criteria that are directly verifiable - from the ground, or
>  from the law. Maybe, in certain developed countries, the system is so
>  well organized that merely checking signs/laws is sufficient. That
>  does not mean it is like that everywhere on the planet.
> 
>  OSM has so far 

Re: [OSM-talk-fr] cycleway=track et bifurcations

[djakk djakk]

Pour moi, on fusionne piste cyclable et route pour voitures avec
cycleway=track quand on a pas le temps de cartographier plus précisément.

Pour ce cas dont tu parles, on pourrait s’en sortir en codant une
séparation route - piste cyclable sur une petite portion de rue autour du
carrefour.

djakk


Le jeu. 22 févr. 2018 à 22:07,  a écrit :

> Si on a une route principale avec une piste à côté taguée cycleway=track,
> peut-on indiquer que lors d'un carrefour que la voie n'est pas empruntable
> depuis la piste cyclable ?
>
> Si la route débouchant sur la route principale est du côté opposé, comme
> c'est une piste et non une bande cyclable, est-ce que ça ne va pas de soi ?
>
> Sauf qu'au niveau du rendu sur la carte, comme au niveau des moteurs de
> navigation certaines subtilités échappent.
>
> Jean-Yvon
>
> N.B. : je ne suis pas spécialement partisan de cycleway=track, je cherche
> juste des cas incompatibles avec une telle description, au moins des cas où
> la représentation est plus difficile qu'avec une voirie tracée en propre
> (par exemple on pourrait mettre des restrictions pour dire explicitement
> que c'est impossible.
> ___
> 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-es] Carretera sin línea central

[Javier Sánchez Portero]

Si pones lanes=1 implica oneway=yes. Es una carretera de doble sentido.

El 23 de febrero de 2018, 17:00, Jorge Sanz Sanfructuoso 
escribió:

> Yo esas las pongo como lanes=1, no hace falta poner oneway=no . Ya indica
> lo que es con eso.
>
> El vie., 23 feb. 2018 a las 17:55, Javier Sánchez Portero (<
> javiers...@gmail.com>) escribió:
>
>> Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se cual
>> sería el término adecuado en inglés.
>>
>> El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega <
>> i...@sanchezortega.es> escribió:
>>
>>> On 2018-02-23 14:51, Javier Sánchez Portero wrote:
>>>
 Hola

 Hay sitios rurales en los que las carreteras no tienen pintada línea
 central. Pueden ser unclassified, tertiary o incluso secondary. Por
 supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
 etiqueta para indicarlo? El método más heavy sería lanes=1
 oneway=no, pero me resulta.

>>>
>>> Creo que se trata de carreteras de dos carriles (uno por sentido), sin
>>> separación por marcas viales.
>>>
>>> Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:
>>>
>>> En las calzadas con doble sentido de circulación y dos carriles,
 SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.

>>>
>>> Es decir, es perfectamente posible una carretera con calzada de doble
>>> sentido y un carril para cada sentido de la circulación, aun cuando no haya
>>> señales horizontales (línea pintada) que los separen.
>>>
>>>
>>> [1] http://www.dgt.es/es/seguridad-vial/normativa-y-
>>> legislacion/reglamento-trafico/circulacion-general/normas-basicas/
>>>
>>> --
>>> Iván Sánchez Ortega 
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://jorgesanz.es/
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Fernando Trebien]

+1

Administrative classification is not strictly related everywhere to
signage, structure and access rights.

On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk  wrote:
> I know that « trunk »  is country-dependent but why not moving it to a
> worldwide definition ? Administrative classification could be moved to other
> tags :)
>
>
> djakk
>
> Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský 
> a écrit :
>>
>> Greetings
>> I'd like to caution against using this system globally. In Czechia, roads
>> are formally classified into classes, which influence signage, ref numbers
>> and so on. Deploying this system here would make the tag confusing/useless
>> and would likely face enormous backlash. I have no problems with using this
>> system in countries without a clearly defined road classification, but
>> please don't touch the countries where there is no doubt about what class
>> any given road is.
>> Happy mapping!
>>
>> On 22 February 2018 at 16:20, djakk djakk  wrote:
>>>
>>> Hello,
>>>
>>> I totally agree with you, the definition you provide,
>>> administrative-free, tends to the same osm map between countries.
>>>
>>> djakk
>>>
>>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>>>  a écrit :

 Landing on this discussion several months late. I've just heard of it
 by reading a wiki talk page [1].

 Since 13 February 2009, the wiki [2] criticises highway classification
 as problematic/unverifiable. This has also been subject to a lot of
 controversy (and edit wars) in my local community (Brazil), especially
 regarding the effect of (lack of) pavement.

 In trying to achieve greater consensus some years ago, I decided to
 seek opinions elsewhere and finally I arrived at this scheme [3] which
 I think is very useful, if not perfect yet. It can be easily
 summarised like this:
 - trunk: best routes between large/important cities
 - primary: best routes between cities and above
 - secondary: best routes between towns/suburbs and above
 - tertiary: best routes between villages/neighbourhoods and above
 - unclassified: best routes between other place=* and above

 For example, the best route between two villages would be at least
 tertiary. So would be the best route between a village and a town or a
 city. Parts of this route might have a higher class in case they are
 part of a route between more important places.

 It surely raises the problem of determining optimal routes. Maybe a
 sensible criterion would be average travel time without traffic
 congestion. A number of vehicles may be selected for this average -
 could be motorcycle+car+bus+truck, or simply car+truck.

 Early results in my area [4, in Portuguese] seem promising and have
 produced more consensus than any previous proposals. To me, this
 method seems to:
 - resist alternations in classification along the same road
 - work across borders (where classification discontinuities are
 expected because each country is using different classification
 criteria)
 - account for road network topology
 - work in countries with mostly precarious/unpaved roads or
 without/unknown official highway classes
 - work between settlements as well as within settlements

 Borderline cases are probably inescapable in any system that does not
 use solely criteria that are directly verifiable - from the ground, or
 from the law. Maybe, in certain developed countries, the system is so
 well organized that merely checking signs/laws is sufficient. That
 does not mean it is like that everywhere on the planet.

 OSM has so far received a lot of input from communities in developed
 countries (mostly Europe, North America and Australia) and hasn't
 given much attention to less developed/organized countries. What comes
 closest to this is what the HOT Team does, but the judgment of road
 classification one can do from satellite images in a foreign country
 is much more limited than the criteria that have been raised in this
 thread so far.

 I wouldn't endorse tags such as maxspeed:practical due to lack of
 verifiability (it should be obvious that different types of vehicles
 would achieve different practical speeds). It is better to use the
 legal speed in maxspeed=* and describe the practical reason for a
 lower speed using surface=*, smoothness=*, and, who knows, maybe the
 not yet approved hazard=* [5] (though that is intended for signed
 hazards, not subjective/opinionated hazards).

 For the sake of long-term sanity, I also wouldn't mix the purpose of
 one tag with the purpose of other tags. To describe the surface, there
 is surface=*, smoothness=* and tracktype=*. To describe access rights,
 there is 

Re: [OSM-talk-fr] Zones géographiques informelles

[djakk djakk]

Noeud, ligne ou surface selon les cas (quartier de ville - fond de vallée -
massif montagneux).
Quant au polygone, quand la limite est floue, en faire un petit et un grand
(cœur de la region - extension maximum de la région) ?


djakk


Le ven. 23 févr. 2018 à 17:58, Philippe Verdy  a écrit :

> Je ne vois pas mettre ça dans les rôles des membres de relations, mais
> directement comme tags des chemins tracés... Le rôle est strictement le
> même ce n'est que la précision du tracé qui est floue (en fait la précision
> des noeuds utilisés, mais on na va pas taguer nécessairement tous les
> noeuds d'un chemin, d'autant plus que ce tracé peut passer ou coïncider
> localement à des points précis (ils le seront s'ils ont des tags utiles,
> non ignorés, c'est à dire non suppressibles automatiquement comme les tags
> d'import automatique, ainsi que certains tags purement informatifs comme
> "note=*" ou "source=*").
>
> Ajouter des rôles (en plus avec un nom anglo-français horrible ) ne va
> pas aider du tout. C'est la géométrie qui est concernée (donc au plus près
> du tracé de bas niveau, donc sur les noeuds, voire les chemins si ce sont
> de noeuds "anonymes").
>
> Le 23 février 2018 à 14:53, Jérôme Amagat  a
> écrit :
>
>> Un node c'est déjà pas mal mais on perd pas mal par rapport a un polygone
>> au niveau de la taille, de l’étendu.
>> Pour les lieux habités place=city town village hamlet ... on a une idée
>> de la taille dans le tag mais comment ont fait pour différencier par
>> exemple les Alpes et un de ses massifs?
>>
>> Un truc que je trouverais pas mal c'est créer une relation multipolygon
>> avec des membres qui ont des rôles du type "outer_approximatif" voir
>> "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
>> pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
>> une cote, une crête de montagne ou au milieu de nul part.
>>
>> Les limites de la zone ne sont pas le seul problème, quel tag doit on
>> utiliser?
>> Il n'y a rien (ou presque) sur le wiki.
>> Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
>> donne la raison d’être de ce nom comme une zone liée à son relief (une
>> vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.
>>
>> Deja present dans osm ont peut trouver avec taginfo :
>> des chose en *=mountain_range
>> des natural=plain, natural=plateau
>> ...
>> Pour les vallée il y a
>>
>> J'ai créé quelque "truc" il y a quelques temps :
>> La Bresse : https://www.openstreetmap.org/relation/3078437
>> La Dombes : https://www.openstreetmap.org/relation/3078442
>> Le Jura Français (les communes en zone de montagne donc c'est du naturel
>> lié a de l'administratif)
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Carretera sin línea central

[Jorge Sanz Sanfructuoso]

Yo esas las pongo como lanes=1, no hace falta poner oneway=no . Ya indica
lo que es con eso.

El vie., 23 feb. 2018 a las 17:55, Javier Sánchez Portero (<
javiers...@gmail.com>) escribió:

> Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se cual
> sería el término adecuado en inglés.
>
> El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega <
> i...@sanchezortega.es> escribió:
>
>> On 2018-02-23 14:51, Javier Sánchez Portero wrote:
>>
>>> Hola
>>>
>>> Hay sitios rurales en los que las carreteras no tienen pintada línea
>>> central. Pueden ser unclassified, tertiary o incluso secondary. Por
>>> supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
>>> etiqueta para indicarlo? El método más heavy sería lanes=1
>>> oneway=no, pero me resulta.
>>>
>>
>> Creo que se trata de carreteras de dos carriles (uno por sentido), sin
>> separación por marcas viales.
>>
>> Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:
>>
>> En las calzadas con doble sentido de circulación y dos carriles,
>>> SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.
>>>
>>
>> Es decir, es perfectamente posible una carretera con calzada de doble
>> sentido y un carril para cada sentido de la circulación, aun cuando no haya
>> señales horizontales (línea pintada) que los separen.
>>
>>
>> [1]
>> http://www.dgt.es/es/seguridad-vial/normativa-y-legislacion/reglamento-trafico/circulacion-general/normas-basicas/
>>
>> --
>> Iván Sánchez Ortega 
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanz.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Je ne vois pas mettre ça dans les rôles des membres de relations, mais
directement comme tags des chemins tracés... Le rôle est strictement le
même ce n'est que la précision du tracé qui est floue (en fait la précision
des noeuds utilisés, mais on na va pas taguer nécessairement tous les
noeuds d'un chemin, d'autant plus que ce tracé peut passer ou coïncider
localement à des points précis (ils le seront s'ils ont des tags utiles,
non ignorés, c'est à dire non suppressibles automatiquement comme les tags
d'import automatique, ainsi que certains tags purement informatifs comme
"note=*" ou "source=*").

Ajouter des rôles (en plus avec un nom anglo-français horrible ) ne va
pas aider du tout. C'est la géométrie qui est concernée (donc au plus près
du tracé de bas niveau, donc sur les noeuds, voire les chemins si ce sont
de noeuds "anonymes").

Le 23 février 2018 à 14:53, Jérôme Amagat  a écrit
:

> Un node c'est déjà pas mal mais on perd pas mal par rapport a un polygone
> au niveau de la taille, de l’étendu.
> Pour les lieux habités place=city town village hamlet ... on a une idée de
> la taille dans le tag mais comment ont fait pour différencier par exemple
> les Alpes et un de ses massifs?
>
> Un truc que je trouverais pas mal c'est créer une relation multipolygon
> avec des membres qui ont des rôles du type "outer_approximatif" voir
> "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
> pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
> une cote, une crête de montagne ou au milieu de nul part.
>
> Les limites de la zone ne sont pas le seul problème, quel tag doit on
> utiliser?
> Il n'y a rien (ou presque) sur le wiki.
> Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
> donne la raison d’être de ce nom comme une zone liée à son relief (une
> vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.
>
> Deja present dans osm ont peut trouver avec taginfo :
> des chose en *=mountain_range
> des natural=plain, natural=plateau
> ...
> Pour les vallée il y a
>
> J'ai créé quelque "truc" il y a quelques temps :
> La Bresse : https://www.openstreetmap.org/relation/3078437
> La Dombes : https://www.openstreetmap.org/relation/3078442
> Le Jura Français (les communes en zone de montagne donc c'est du naturel
> lié a de l'administratif)
>
>
> ___
> 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-es] Carretera sin línea central

[Javier Sánchez Portero]

Correcto. ¿Pero existirá alguna etiqueta tipo central_line=no? No se cual
sería el término adecuado en inglés.

El 23 de febrero de 2018, 15:32, Iván Sánchez Ortega 
escribió:

> On 2018-02-23 14:51, Javier Sánchez Portero wrote:
>
>> Hola
>>
>> Hay sitios rurales en los que las carreteras no tienen pintada línea
>> central. Pueden ser unclassified, tertiary o incluso secondary. Por
>> supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
>> etiqueta para indicarlo? El método más heavy sería lanes=1
>> oneway=no, pero me resulta.
>>
>
> Creo que se trata de carreteras de dos carriles (uno por sentido), sin
> separación por marcas viales.
>
> Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:
>
> En las calzadas con doble sentido de circulación y dos carriles, SEPARADOS
>> O NO POR MARCAS VIALES, circulará por el de su derecha.
>>
>
> Es decir, es perfectamente posible una carretera con calzada de doble
> sentido y un carril para cada sentido de la circulación, aun cuando no haya
> señales horizontales (línea pintada) que los separen.
>
>
> [1] http://www.dgt.es/es/seguridad-vial/normativa-y-legislacion/
> reglamento-trafico/circulacion-general/normas-basicas/
>
> --
> Iván Sánchez Ortega 
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Digest di Talk-it, Volume 135, Numero 99

[gianluigi salvucci]

scusatemi sono nuovo spero di non far casinoho visto anche io il video e 
lavorando sul catasto quotidianamente ho notato che il link è cambiato
questo è quello corretto e 
funzionahttp://www.agenziaentrate.gov.it/wps/content/nsilib/nsi/schede/fabbricatiterreni/consultazione+cartografia+catastale/servizio+consultazione+cartografia/indice+servizio+consultazione+cartografia
occupandomi di censimento edifici sposo caladamente l'idea di non usarlo.
si tratta  del risultato di un accatastamento cosa ben diversa da un rilievo.
Tra l'altro non tutto viene censito e credo ma vi invito a verificare i 
poligoni che non hanno etichette catastali (i non accatastati per intendersi) 
sono stati presi da OPEN STREET MAP.
senza voler sollevare polemiche è un dato di fatto non hanno l'intera copertura 
ma solo l'idea che in quel luogo esiste un edificio, potrebbe essere stato 
abbattuto e loro non lo sanno fintanto che non cambia l'accatasmento.
la rilevazione sul campo secondo me è molto più efficiente
grazie a tutti fate un lavoro fantastico e spero di potervi essere d'aiuto.

 

Il Venerdì 23 Febbraio 2018 13:49, "talk-it-requ...@openstreetmap.org" 
 ha scritto:
 

 Invia le richieste di iscrizione alla lista Talk-it all'indirizzo
    talk-it@openstreetmap.org

Per iscriverti o cancellarti attraverso il web, visita
    https://lists.openstreetmap.org/listinfo/talk-it
oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
    talk-it-requ...@openstreetmap.org

Puoi contattare la persona che gestisce la lista all'indirizzo
    talk-it-ow...@openstreetmap.org

Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
in modo che sia più utile di un semplice "Re: Contenuti del digest
della lista Talk-it..."


Argomenti del Giorno:

  1. Re: risposta a dichiarazione uso di GoogleStreetView
      (Cascafico Giovanni)
  2. Re: WMS mappa catasto agenzia delle entrate non funziona
      più? (carlo folini)


--

Message: 1
Date: Fri, 23 Feb 2018 13:47:16 +0100
From: Cascafico Giovanni 
To: openstreetmap list - italiano 
Subject: Re: [Talk-it] risposta a dichiarazione uso di
    GoogleStreetView
Message-ID:
    

Re: [Talk-ca] Formatting of Municipality Names in Ontario

[Matthew Darwin]

I will leave the wonky towns (the ones that have parentheses) for 
cleanup later.  The other "Town Of" are done.


I am working on "Municipality Of" now.

On 2018-02-18 11:04 PM, Matthew Darwin wrote:


Hi Bill,

Thanks for the feedback.  OSM is updated accordingly.

I also changed "City of Prince Edward County" to "Prince Edward" (I 
didn't receive any comments on that one).   "City Of" updates in 
Ontario is now complete (at least until someone adds another one).


Updates to "Town Of" are now in  progress.   If anyone has comments 
about how to handle the following please do speak up:


   3053 Town of the Blue Mountains   => "Blue Mountains"  [remove "the"]
 14 Town of Caledon (Bolton)
  2 Town of Whitchurch-Stouffville (Stouffville)
  2 Town of Caledon (Sandhill)
  1 Town of Saugeen Shores (Southampton)
  1 Town of Mono (Rosemont)
  1 Town of Huntsville (Port Sydney)
  1 Town of Clarington (Enniskillen)

Following towns, I will be updating "Municipality Of" (after that 
"Township Of").  The list for "Municipality Of" is:


  22881 Municipality of Chatham-Kent
   9906 Municipality of Clarington
   3962 Municipality of West Grey
   3929 Municipality of Grey Highlands
   3815 Municipality of Kincardine
   3690 Municipality of Trent Hills
   3549 Municipality of Leamington
   3543 Municipality of Middlesex Centre
   3293 Municipality of Port Hope
   3284 Municipality of North Grenville
   3192 Municipality of Brockton
   2794 Municipality of Meaford
   2793 Municipality of Highlands East
   2706 Municipality of Arran-Elderslie
   2462 Municipality of Thames Centre
   2439 Municipality of the Nation
   2418 Municipality of Tweed
   2320 Municipality of Southwest Middlesex
   2275 Municipality of Brighton
   2194 Municipality of North Perth
   2145 Municipality of Northern Bruce Peninsula
   1981 Municipality of Central Elgin
   1634 Municipality of South Bruce
   1501 Municipality Of Greenstone
   1462 Municipality of Marmora and Lake
   1424 Municipality of Oliver Paipoonge
   1374 Municipality of Hastings Highlands
   1265 Municipality of Centre Hastings
   1227 Municipality of West Nipissing
   1197 Municipality of Brooke-Alvinston
   1168 Municipality of Bayham
   1060 Municipality of Whitestone
   1015 Municipality of McDougall
    989 Municipality of French River
    943 Municipality of Wawa
    895 Municipality of Magnetawan
    817 Municipality of Shuniah
    790 Municipality of Lambton Shores
    710 Municipality Of Markstay-warren
    665 Municipality of Neebing
    634 Municipality Of Huron Shores
    460 Municipality of West Elgin
    414 Municipality of Huron Shores
    367 Municipality of Dutton/Dunwich
    293 Municipality Of St.-charles
    281 Municipality of Powassan
    236 Municipality of North Middlesex
    165 Municipality of Killarney
 47 Municipality Of West Nipissing
 46 Municipality Of Charlton And Dack
 23 Municipality Of Wawa
 18 Municipality of Callander
  7 Municipality Of Sioux Lookout
  4 Municipality Of Killarney
  2 Municipality Of French River
  1 Municipality of Brockton;Municipality of South Bruce


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

[OSRM-talk] OSRM v5.16.0 Release

[Chau Nguyen]

Hello!

We just released OSRM v5.16, focusing on improving guidance and profiles. 
This release ships several fixes but also new features. Highlights of new
features are:

### Maneuver Override Relations:

Sometimes road geometries of complicated intersections do not give enough
information on how a suitable guidance should look like. OSRM is now
supporting the `maneuver override` tag in OSM to detect such intersections
and choose better guidance. Read more about the `maneuver override` tag
here:
https://github.com/Project-OSRM/osrm-backend/wiki/Maneuver-override-tag

### Turn functions in Lua Profiles:

When setting turn durations and weights, the `process_turn` function in the
lua profiles only gave limited access to attributes to identify the
intersection where the turn is happening. We added more attributes such
that we can set durations and weights based on more information such as
highway tags. Read more about the attributes here:
https://github.com/Project-OSRM/osrm-backend/blob/master/docs/profiles.md#process_turnprofile-turn


### Here is the complete Changelog:

Changes from 5.15.2 to 5.16.0:

- Guidance
  - ADDED #4676: Support for maneuver override relation, allowing
data-driven overrides for turn-by-turn instructions [#4676](
https://github.com/Project-OSRM/osrm-backend/pull/4676)
  - CHANGED #4830: Announce reference change if names are empty
  - CHANGED #4835: MAXIMAL_ALLOWED_SEPARATION_WIDTH increased to 12 meters
  - CHANGED #4842: Lower priority links from a motorway now are used as
motorway links [#4842](
https://github.com/Project-OSRM/osrm-backend/pull/4842)
  - CHANGED #4895: Use ramp bifurcations as fork intersections [#4895](
https://github.com/Project-OSRM/osrm-backend/issues/4895)
  - CHANGED #4893: Handle motorway forks with links as normal motorway
intersections[#4893](
https://github.com/Project-OSRM/osrm-backend/issues/4893)
  - FIXED #4905: Check required tags of `maneuver` relations [#4905](
https://github.com/Project-OSRM/osrm-backend/pull/4905)
- Profile:
  - FIXED: `highway=service` will now be used for restricted access,
`access=private` is still disabled for snapping.
  - ADDED #4775: Exposes more information to the turn function, now being
able to set turn weights with highway and access information of the turn as
well as other roads at the intersection [#4775](
https://github.com/Project-OSRM/osrm-backend/issues/4775)
  - FIXED #4763: Add support for non-numerical units in car profile for
maxheight [#4763](https://github.com/Project-OSRM/osrm-backend/issues/4763)
  - ADDED #4872: Handling of `barrier=height_restrictor` nodes [#4872](
https://github.com/Project-OSRM/osrm-backend/pull/4872)

You can compile OSRM from source, use the pre-built binaries we ship with
node-osrm or use our Docker images. Always happy to hear your feedback! 

Cheers,
Chau
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

I know that « trunk »  is country-dependent but why not moving it to a
worldwide definition ? Administrative classification could be moved to
other tags :)


djakk

Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský 
a écrit :

> Greetings
> I'd like to caution against using this system globally. In Czechia, roads
> are formally classified into classes, which influence signage, ref numbers
> and so on. Deploying this system here would make the tag confusing/useless
> and would likely face enormous backlash. I have no problems with using this
> system in countries without a clearly defined road classification, but
> please don't touch the countries where there is no doubt about what class
> any given road is.
> Happy mapping!
>
> On 22 February 2018 at 16:20, djakk djakk  wrote:
>
>> Hello,
>>
>> I totally agree with you, the definition you provide,
>> administrative-free, tends to the same osm map between countries.
>>
>> djakk
>>
>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien <
>> fernando.treb...@gmail.com> a écrit :
>>
>>> Landing on this discussion several months late. I've just heard of it
>>> by reading a wiki talk page [1].
>>>
>>> Since 13 February 2009, the wiki [2] criticises highway classification
>>> as problematic/unverifiable. This has also been subject to a lot of
>>> controversy (and edit wars) in my local community (Brazil), especially
>>> regarding the effect of (lack of) pavement.
>>>
>>> In trying to achieve greater consensus some years ago, I decided to
>>> seek opinions elsewhere and finally I arrived at this scheme [3] which
>>> I think is very useful, if not perfect yet. It can be easily
>>> summarised like this:
>>> - trunk: best routes between large/important cities
>>> - primary: best routes between cities and above
>>> - secondary: best routes between towns/suburbs and above
>>> - tertiary: best routes between villages/neighbourhoods and above
>>> - unclassified: best routes between other place=* and above
>>>
>>> For example, the best route between two villages would be at least
>>> tertiary. So would be the best route between a village and a town or a
>>> city. Parts of this route might have a higher class in case they are
>>> part of a route between more important places.
>>>
>>> It surely raises the problem of determining optimal routes. Maybe a
>>> sensible criterion would be average travel time without traffic
>>> congestion. A number of vehicles may be selected for this average -
>>> could be motorcycle+car+bus+truck, or simply car+truck.
>>>
>>> Early results in my area [4, in Portuguese] seem promising and have
>>> produced more consensus than any previous proposals. To me, this
>>> method seems to:
>>> - resist alternations in classification along the same road
>>> - work across borders (where classification discontinuities are
>>> expected because each country is using different classification
>>> criteria)
>>> - account for road network topology
>>> - work in countries with mostly precarious/unpaved roads or
>>> without/unknown official highway classes
>>> - work between settlements as well as within settlements
>>>
>>> Borderline cases are probably inescapable in any system that does not
>>> use solely criteria that are directly verifiable - from the ground, or
>>> from the law. Maybe, in certain developed countries, the system is so
>>> well organized that merely checking signs/laws is sufficient. That
>>> does not mean it is like that everywhere on the planet.
>>>
>>> OSM has so far received a lot of input from communities in developed
>>> countries (mostly Europe, North America and Australia) and hasn't
>>> given much attention to less developed/organized countries. What comes
>>> closest to this is what the HOT Team does, but the judgment of road
>>> classification one can do from satellite images in a foreign country
>>> is much more limited than the criteria that have been raised in this
>>> thread so far.
>>>
>>> I wouldn't endorse tags such as maxspeed:practical due to lack of
>>> verifiability (it should be obvious that different types of vehicles
>>> would achieve different practical speeds). It is better to use the
>>> legal speed in maxspeed=* and describe the practical reason for a
>>> lower speed using surface=*, smoothness=*, and, who knows, maybe the
>>> not yet approved hazard=* [5] (though that is intended for signed
>>> hazards, not subjective/opinionated hazards).
>>>
>>> For the sake of long-term sanity, I also wouldn't mix the purpose of
>>> one tag with the purpose of other tags. To describe the surface, there
>>> is surface=*, smoothness=* and tracktype=*. To describe access rights,
>>> there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
>>> describe legal speed, maxspeed=*. To describe curves, there's
>>> geometry.
>>>
>>> Purpose, perhaps, is the main issue. What is the purpose of highway
>>> classification? Is it to save us the work of adding extra tags? Is it
>>> to allow the 

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Alessandro]

Il 23/02/2018 16:26, Ivo Reano ha scritto:



Il giorno 23 febbraio 2018 15:58, Simone Saviolo 
> ha scritto:


Però si potrebbe introdurre un'accademia. Neanche tanto per
insegnare come si mappa, quanto piuttosto per porre una barriera
all'ingresso. Va bene che la si voglia tenere bassa, ma non può
essere nulla. Anche solo un tutorial con verifica finale
eliminerebbe il 99,9% dei mappatori svogliati e dei vandali casuali
(rimarrebbe lo 0,1% di batteri indistruttibili).


Quest'ultima mi sembra interessante e fattibile, oltre che divertente!




Ecco che quando si discute di cose sensate ;-) (pensando a decine di 
argomenti che finiscono direttamente nel cestino) arrivano idee sensate.


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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

Ideálně Mirkovi Suchému.

Díky,
Marián

-- Původní e-mail --
Od: Petr Vozdecký 
Komu: OpenStreetMap Czech Republic 
Datum: 23. 2. 2018 16:38:23
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )
"Jo Mariane, udělám to. Jak postupovat? Komu to mám poslat, az to zplodim?
-- Původní e-mail --
Od: Marián Kyral Jinak díky za postřehy, všechno je to
stále ve vývoji. Bylo by super, kdyby sis našel trochu času a upravil popis
na TaskManageru, aby to bylo pro nováčky srozumitelnější.
"


"___
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] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

Jo Mariane, udělám to. Jak postupovat? Komu to mám poslat, az to zplodim?
-- Původní e-mail --
Od: Marián Kyral Jinak díky za postřehy, všechno je to
stále ve vývoji. Bylo by super, kdyby sis našel trochu času a upravil popis
na TaskManageru, aby to bylo pro nováčky srozumitelnější.
"


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

Re: [Talk-es] Carretera sin línea central

[Iván Sánchez Ortega]

On 2018-02-23 14:51, Javier Sánchez Portero wrote:

Hola

Hay sitios rurales en los que las carreteras no tienen pintada línea
central. Pueden ser unclassified, tertiary o incluso secondary. Por
supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
etiqueta para indicarlo? El método más heavy sería lanes=1
oneway=no, pero me resulta.


Creo que se trata de carreteras de dos carriles (uno por sentido), sin 
separación por marcas viales.


Cito código de circulación de 2003[1], artículo 30.1.a, énfasis mío:

En las calzadas con doble sentido de circulación y dos carriles, 
SEPARADOS O NO POR MARCAS VIALES, circulará por el de su derecha.


Es decir, es perfectamente posible una carretera con calzada de doble 
sentido y un carril para cada sentido de la circulación, aun cuando no 
haya señales horizontales (línea pintada) que los separen.



[1] 
http://www.dgt.es/es/seguridad-vial/normativa-y-legislacion/reglamento-trafico/circulacion-general/normas-basicas/


--
Iván Sánchez Ortega 

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Ivo Reano]

Il giorno 23 febbraio 2018 15:58, Simone Saviolo 
ha scritto:

> Però si potrebbe introdurre un'accademia. Neanche tanto per insegnare come
> si mappa, quanto piuttosto per porre una barriera all'ingresso. Va bene che
> la si voglia tenere bassa, ma non può essere nulla. Anche solo un tutorial
> con verifica finale eliminerebbe il 99,9% dei mappatori svogliati e dei
> vandali casuali (rimarrebbe lo 0,1% di batteri indistruttibili).
>

Quest'ultima mi sembra interessante e fattibile, oltre che divertente!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

-- Původní e-mail --
Od: Petr Vozdecký 
Komu: OpenStreetMap Czech Republic 
Datum: 23. 2. 2018 14:52:47
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )
"Překvapivě mi prakticky všichni (které jsem z Talk-cz neznal) řekli, že
Talk-cz aktivně sledují, jen do něj nepřispívají, protože se domnívají, že
ti, co do něj píšou, jsou geekové a oni by si připadali se svými dotazy
blbě. OSM komunita je totiž tvořena daleko více než jiné průměrné skupiny
lidí jedinci spíše uzavřenými - no a těm je potřeba jít spíše naproti... :)
"



A máš nějaký nápad, jak tuto konferenci odgeekovat? České diskuzní fórum na
osm.org sice funguje, ale moc se nepoužívá. Převést na jinou platformu? Nebo
jen napojit, s tím, že by mail konference fungovala dále, ale bylo by možné
diskutovat i jinak než přes email.





Jako jednu z nevýhod mail konference vidím to, že nově příchozí nemůže
přispět do nějaké starší, již neaktivní, diskuse. Možná kdyby @zby_cz
doplnil tuto funkcionalitu na https://openstreetmap.cz/talkcz





Marián

BTW: co uděláme s tagem kct_barva? Na OpenAltu jsme se shodli, že tag již
není potřeba, ale zatím se nepodařilo změnu uvést v život. Tedy projít,
doplnit, opravit původní návrh, projít wiki, zjistit co bude potřeba opravit
- třeba kčt preset v JOSM.

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

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Simone Saviolo]

Il giorno 23 febbraio 2018 14:48, Alessandro  ha
scritto:

> Quando l’articolo affronta il primo tema della contrarietà di permettere a
> chiunque e senza limiti di accedere alle risorse di osm.org vorrei
> ricordare un periodo di rallentamento del sito dovuto al boom di alcune app
> che utilizzavano le tiles osm on line. Proprio in quel periodo furono
> redatte le linee guida che si leggono ancora oggi sul giusto (fair)
> utilizzo delle risorse osm. E se togliessimo ogni limite accetteremmo che
> la risposta dei server fosse molto più lenta? E così come noi farebbero
> anche le altre persone che fruiscono solo di mappe e servizi OSM?
>

È stata valutata la possibilità di sfruttare le nuove tecnologie di
distributed computing? AWS, Google Cloud o Microsoft Azure permettono di
scalare il servizio necessario in maniera facile, veloce, e abbastanza
economica (soprattutto evitando lo spreco: se oggi mi servono 50 TB di
trasferimento e domani 90, non ho bisogno di pagare 100 TB per due giorni).
Certo, richiede che il software sia scritto in un certo modo, e
probabilmente nel 2009 non era stato fatto così.

Non entro nel merito del potenziale conflitto d’interessi anche se
> personalmente sorrido quando si pongono certi problemi ragionando sull’oggi
> senza pensare che il mercato dell’informazione geografica sta avendo e avrà
> una crescita esponenziale, quindi ritengo che per diversi anni ci sarà
> posto per tutti.
> Sulla bizzarria del limitare l’accesso a chi utilizza più del 5% delle
> risorse vale lo stesso ragionamento espresso sopra: apriamo tutto e ci
> accontentiamo di vedere il tutto rallentato?
>

La bizzarria di cui si parla non sta tanto nel limite (cosa buona e giusta,
e praticata da chiunque offra un servizio), quanto nella definizione
assurda. Perché non si può dire "massimo X tile al giorno", o "massimo Y MB
al giorno"?

Personalmente la moderazione la vedo come un rallentare i contributi.
> Recentemente OSM a Genova ha acquisito un ottimo ed esperto contributore
> che era stufo di aspettare settimane per vedere i propri contributi
> accettati da una mappa proprietaria a cui contribuiva. Posso essere
> d’accordo sullo studiare un sistema per alcune caratteristiche (leggasi
> linee di costa o confini) ma, almeno allo stato attuale una moderazione per
> qualsiasi contributo la vedo molto male.
>

Però si potrebbe introdurre un'accademia. Neanche tanto per insegnare come
si mappa, quanto piuttosto per porre una barriera all'ingresso. Va bene che
la si voglia tenere bassa, ma non può essere nulla. Anche solo un tutorial
con verifica finale eliminerebbe il 99,9% dei mappatori svogliati e dei
vandali casuali (rimarrebbe lo 0,1% di batteri indistruttibili).

Ciao,

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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Matej Lieskovský]

I'd like to reiterate that (much like riverbanks) the shoreline of a lake
can change far faster than the river channel. While the area maps the
"usual" extent (ignoring droughts and floods), the line is a very useful
abstraction.

Not connecting rivers into a network invalidates the idea of a network in
the first place and will lead to loss of data usefulness. This might lead
to wide rivers no longer getting a centerline (bacause what's the point if
everyone must work with the areas?) and will set a precedent that might get
used by (for example) highway:area proponents to do the same to the road
network. (No offence to the proponents of highway:area intended.) I'm
almost curious as to what mayhem would replacing roads with areas cause.

Should we not go the opposite direction and make sure that all rivers are
either tributaries, or flow into an ocean or a lake that would get tagged
with "no outflow"? I wouldn't be surprised to find out that someone already
does that.

On 23 February 2018 at 15:50, François Lacombe 
wrote:

> 2018-02-23 15:36 GMT+01:00 Rory McCann :
>
>> If OSM takes a "all rivers must be connected through lakes", then data
>> consumers have a simple job. If OSM says "some will and some won't", then
>> data consumers have to process the data to add intra-lake connections. If
>> they have to do it some of the time, why bother connecting *any* rivers?
>>
>
> IMHO rivers should always connect through lakes. I'm always mapping like
> this, no exception.
>
>
>> I think I'll change to not connecting rivers, unless it's very obvious,
>> and leaving data consumers to connect rivers themselves.
>>
> This may be a very hard task, especially if rivers don't share nodes witk
> lakes waterbody.
>
> François
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[François Lacombe]

2018-02-23 15:36 GMT+01:00 Rory McCann :

> If OSM takes a "all rivers must be connected through lakes", then data
> consumers have a simple job. If OSM says "some will and some won't", then
> data consumers have to process the data to add intra-lake connections. If
> they have to do it some of the time, why bother connecting *any* rivers?
>

IMHO rivers should always connect through lakes. I'm always mapping like
this, no exception.


> I think I'll change to not connecting rivers, unless it's very obvious,
> and leaving data consumers to connect rivers themselves.
>
This may be a very hard task, especially if rivers don't share nodes witk
lakes waterbody.

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

Re: [OSM-talk] Is this legal to what philly.com is doing?

[Paul Norman]

On 2/22/2018 8:03 PM, James Mast wrote:

http://www.philly.com/philly/news/politics/will-republicans-impeach-pennsylvania-supreme-court-justices-20180222.html

(ignore what the article is about)


Just happen to see a thumbnail and clicked on the article since I 
noticed the OSM base map.  Nowhere that I can find does it give credit 
to OSM for the use of it.



Now, the part to where I was curious if this was legal (sans the lack 
of credit), is that they are 'selling' the uploaded image.  Is that 
allowed currently under the license that OSM has?





Yes. They need to either be attributing OSM, or if the image is taken 
from an osm.org render, attributing OSM and licensing it CC BY-SA.


A key feature of open licenses is that they do not discriminate by field 
of use, which includes commercial use. Someone who purchased the image 
can either reuse the underlying data under the ODbL, or, in the case of 
a CC BY-SA image, also reuse the image.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Rory McCann]

On 23/02/18 11:58, François Lacombe wrote:

If some rivers/streams shouldn't be connected, then some data consumers
will have to do an automatic connection anyway. When measuring water run
off and pollution, you probably want to know that "stuff going into
stream X will eventually get to point Y downstream" (right?).

I don't get this, which situation do you think of when you say " If some 
rivers/streams shouldn't be connected " ?


If OSM takes a "all rivers must be connected through lakes", then data 
consumers have a simple job. If OSM says "some will and some won't", 
then data consumers have to process the data to add intra-lake 
connections. If they have to do it some of the time, why bother 
connecting *any* rivers?


I think I'll change to not connecting rivers, unless it's very obvious, 
and leaving data consumers to connect rivers themselves.


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

Re: [Talk-ca] Talk-ca Digest, Vol 120, Issue 48

[Jonathan Brown]

I don’t mind trying to contact the school, Fredrick. I have a few contacts with 
the two Ottawa school boards. 

Jonathan Brown

From: talk-ca-requ...@openstreetmap.org
Sent: Friday, February 23, 2018 7:00 AM
To: talk-ca@openstreetmap.org
Subject: Talk-ca Digest, Vol 120, Issue 48

Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to
talk-ca-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ca-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-ca digest..."


Today's Topics:

   1. Issues with an Ottawa school (Frederik Ramm)
   2. Re: Issues with an Ottawa school (John Marshall)
   3. Re: Issues with an Ottawa school (James)
   4. Re: Issues with an Ottawa school (Frederik Ramm)


--

Message: 1
Date: Thu, 22 Feb 2018 19:58:49 +0100
From: Frederik Ramm 
To: Talk-CA OpenStreetMap 
Subject: [Talk-ca] Issues with an Ottawa school
Message-ID: <3719fdd3-d8f0-0c37-cebb-ccd7d4e6e...@remote.org>
Content-Type: text/plain; charset=utf-8

Hi,

DWG has received a complaint about a fictional village in Africa,

https://www.openstreetmap.org/#map=18/16.36752/-3.47617

and after investigation it turns out that a total of 120 user accounts
have been created on January 25th, using email addresses that point to
one particular unified school district in Ottawa.

76 of these have made edits, some of which are legitimate tracings of
buildings in Africa, but the majority are "funny" edits like the ones
you see in the link above, in various places in Africa and occasionally
the US. Objects with names like "Get dunked on", "The Ocean of
Awsomeness with Vianey, Sarah, Maddy and Aubrey not Abby", "the abanoned
mushroom railroad", "some fenced in area", "The Monkey Park" - the usual
teenage stuff.

I don't have the time to sort the good from the bad, and given that none
of the pupils/students were active after January 26th, I'll probably
revert the lot.

Would anybody be willing to try and make contact with the school
district in question, and try to find out who is responsible? It is
certainly a good idea to introduce young people to OSM, but apparently
with 120 in one go, teachers/instructors were unable to provide the
necessary guidance for this to become a success. (I have not seen any
attempts of organised cleanup either.)

It would be good if the organisers responsible had a contact into the
Ottawa OSM community so they could ask for support next time they plan
something like this.

(As a side note, most accounts seem to have been set up using real
names, which perhaps also is not best practice for teenage editing,
*especially* if most of the data contributed is actually detrimental to
OSM.)

If someone steps forward, I would furnish them with details in a
personal email so as to avoid publicly tarnishing the reputation of the
school in question ;)

Our aim is not to accuse, but to help them understand the issue, and do
better next time. It would be ideal if whoever steps forward possesses
the diplomacy skills necessary to get that across.

Bye
Frederik

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



--

Message: 2
Date: Thu, 22 Feb 2018 14:06:38 -0500
From: John Marshall 
To: Frederik Ramm 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] Issues with an Ottawa school
Message-ID:

Content-Type: text/plain; charset="utf-8"

Good day Frederik,

I would.

John Marshall
Ottawa


On Thu, Feb 22, 2018 at 1:58 PM, Frederik Ramm  wrote:

> Hi,
>
> DWG has received a complaint about a fictional village in Africa,
>
> https://www.openstreetmap.org/#map=18/16.36752/-3.47617
>
> and after investigation it turns out that a total of 120 user accounts
> have been created on January 25th, using email addresses that point to
> one particular unified school district in Ottawa.
>
> 76 of these have made edits, some of which are legitimate tracings of
> buildings in Africa, but the majority are "funny" edits like the ones
> you see in the link above, in various places in Africa and occasionally
> the US. Objects with names like "Get dunked on", "The Ocean of
> Awsomeness with Vianey, Sarah, Maddy and Aubrey not Abby", "the abanoned
> mushroom railroad", "some fenced in area", "The Monkey Park" - the usual
> teenage stuff.
>
> I don't have the time to sort the good from the bad, and given that none
> of the pupils/students were active after January 26th, I'll probably
> revert the lot.
>
> Would anybody 

[OSM-talk] OpenStreetMap Carto release v4.8.0

[Daniel Koć]

Dear all,

Today, v4.8.0 of the openstreetmap-carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are 
deployed on the openstreetmap.org it will take couple of days before all 
tiles show the new rendering.


Changes include
- Made military area rendering less prominent
- Adding rendering for historic=wayside_shrine
- Adding rendering for historic=fort
- Adding rendering for amenity=public_bath
- Adding rendering for shop=chocolate
- Adding rendering for barrier=toll_booth (nodes)
- Adding rendering barrier=log
- Adding rendering for amenity=waste_disposal
- Moving tourism-boundary under barrier layer
- Docker: run osm2pgsql in slim mode
- Fix operator precedence for hstore queries
- Small documentation fixes

Thanks to all the contributors for this release, including jbelien, 
MKuranowski, andrzej-r and Zverik, new contributors.


For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.7.0...v4.8.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[majka]

Opravdu si myslíš, že průměrný mapper bude:
1. zkoumat, proč POI-importer dělá to co dělá (a nemávne nad případnou
chybou rukou)
2. bude zkoumat, proč Česká pošta funguje tak jak funguje
3. vyhodí do talku 3 dotazy během 10 minut a nedá čas na odpověď?

Protože v tu chvíli se nad sebou musím zamyslet. Nečekala jsem, že jsem zas
tak daleko od průměru ;)

Teď ale vážně:
Dej vědět, co přesně by se podle Tebe mělo změnit. Protože je mi naprosto
jasné, že co já považuji po více než roce se hrabání se schránkami za
samozřejmé, zas tak samozřejmé nebude. Ale jakmile se někde začnu
rozepisovat, je toho moc najednou, a času taky není neomezeně.

Majka

2018-02-23 14:51 GMT+01:00 Petr Vozdecký :

> Ahoj,
> snažím se to nekomplikovat, ale naopak se snažím odzkoušet pozici
> průmněrně (i méně) zkušeného mappera, kterého do toho namotivujeme -
> jakmile to nepochopí na první dobrou, tak s tím sekne. Tedy je potřeba na
> toto při jakékoliv komunikaci k mapperům myslet a psát to spíše polopatě. :)
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Zones géographiques informelles

[Jérôme Amagat]

oups c'est parti trop vite :)

Pour les vallée il y a natural=valley mais on est censé indiquer que le
fond de la vallée : https://wiki.openstreetmap.org/wiki/Tag:natural%3Dvalley

Le Jura Français (les communes en zone de montagne donc c'est du naturel
lié à de l'administratif) :
https://www.openstreetmap.org/relation/3078420

Le 23 février 2018 à 14:53, Jérôme Amagat  a écrit
:

> Un node c'est déjà pas mal mais on perd pas mal par rapport a un polygone
> au niveau de la taille, de l’étendu.
> Pour les lieux habités place=city town village hamlet ... on a une idée de
> la taille dans le tag mais comment ont fait pour différencier par exemple
> les Alpes et un de ses massifs?
>
> Un truc que je trouverais pas mal c'est créer une relation multipolygon
> avec des membres qui ont des rôles du type "outer_approximatif" voir
> "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
> pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
> une cote, une crête de montagne ou au milieu de nul part.
>
> Les limites de la zone ne sont pas le seul problème, quel tag doit on
> utiliser?
> Il n'y a rien (ou presque) sur le wiki.
> Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
> donne la raison d’être de ce nom comme une zone liée à son relief (une
> vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.
>
> Deja present dans osm ont peut trouver avec taginfo :
> des chose en *=mountain_range
> des natural=plain, natural=plateau
> ...
> Pour les vallée il y a
>
> J'ai créé quelque "truc" il y a quelques temps :
> La Bresse : https://www.openstreetmap.org/relation/3078437
> La Dombes : https://www.openstreetmap.org/relation/3078442
> Le Jura Français (les communes en zone de montagne donc c'est du naturel
> lié a de l'administratif)
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[Jérôme Amagat]

Un node c'est déjà pas mal mais on perd pas mal par rapport a un polygone
au niveau de la taille, de l’étendu.
Pour les lieux habités place=city town village hamlet ... on a une idée de
la taille dans le tag mais comment ont fait pour différencier par exemple
les Alpes et un de ses massifs?

Un truc que je trouverais pas mal c'est créer une relation multipolygon
avec des membres qui ont des rôles du type "outer_approximatif" voir
"outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
une cote, une crête de montagne ou au milieu de nul part.

Les limites de la zone ne sont pas le seul problème, quel tag doit on
utiliser?
Il n'y a rien (ou presque) sur le wiki.
Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
donne la raison d’être de ce nom comme une zone liée à son relief (une
vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.

Deja present dans osm ont peut trouver avec taginfo :
des chose en *=mountain_range
des natural=plain, natural=plateau
...
Pour les vallée il y a

J'ai créé quelque "truc" il y a quelques temps :
La Bresse : https://www.openstreetmap.org/relation/3078437
La Dombes : https://www.openstreetmap.org/relation/3078442
Le Jura Français (les communes en zone de montagne donc c'est du naturel
lié a de l'administratif)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-es] Carretera sin línea central

[Javier Sánchez Portero]

Hola

Hay sitios rurales en los que las carreteras no tienen pintada línea
central. Pueden ser unclassified, tertiary o incluso secondary. Por
supuesto estoy hablando de carreteras de doble sentido. ¿Hay alguna
etiqueta para indicarlo? El método más heavy sería lanes=1 oneway=no, pero
me resulta.

Ejemplo:
https://goo.gl/maps/oTHb24s9yen
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Why OpenStreetMap is in Serious Trouble

[Alessandro]

Buongiorno lista,
di rientro da una settimana molto pesante (ma anche molto soddisfacente) 
a Roma metto lì i miei due centesimi sulla discussione. E’ un’occasione 
da prendere al volo anche perché quando si tenta di intavolare una 
qualche discussione su temi un poco più alti rispetti ai blasonati 
idranti blu e contenitori di escrementi animali nei giardini non si 
ottengono risposte.


Molti dei problemi evidenziati sono dovuti alla crescita del progetto. 
Altri sono imputabili alla carenza di una valida comunità.


Durante le mie presentazioni ripeto più volte che lo scopo primario di 
OpenStreetMap è creare un database cartografico piuttosto che una mappa. 
Il sito osm.org rappresentando una vetrina del progetto fa però vedere 
una mappa perché mostrare lo schema di un database sarebbe poco 
attrattivo. Purtroppo non abbiamo la potenza di fuoco di chi può gestire 
centinaia di milioni di euro e pertanto possiamo fornire una piccola 
frazione dei servizi possibili principalmente – ma non solo, 
intendiamoci – per carenza di risorse.
All’interno della OSMF, di cui faccio parte ma nella quale non ci sono 
molti italiani, c’è chi ha questa visione, magari un po' nerd, di 
fornire un servizio base lasciando il resto a volontari o aziende; penso 
ricorderete pochi anni fa la discussione che nacque per aggiungere il 
servizio di routing all’interno del sito osm.org.
Ma la foundation è fatta da persone e da un budget limitato. In maniera 
semplicistica potrei dire "entrate a far parte della OSMF e cerchiamo di 
avere una maggior disponibilità di fondi".


Quando l’articolo affronta il primo tema della contrarietà di permettere 
a chiunque e senza limiti di accedere alle risorse di osm.org vorrei 
ricordare un periodo di rallentamento del sito dovuto al boom di alcune 
app che utilizzavano le tiles osm on line. Proprio in quel periodo 
furono redatte le linee guida che si leggono ancora oggi sul giusto 
(fair) utilizzo delle risorse osm. E se togliessimo ogni limite 
accetteremmo che la risposta dei server fosse molto più lenta? E così 
come noi farebbero anche le altre persone che fruiscono solo di mappe e 
servizi OSM?


Non entro nel merito del potenziale conflitto d’interessi anche se 
personalmente sorrido quando si pongono certi problemi ragionando 
sull’oggi senza pensare che il mercato dell’informazione geografica sta 
avendo e avrà una crescita esponenziale, quindi ritengo che per diversi 
anni ci sarà posto per tutti.
Sulla bizzarria del limitare l’accesso a chi utilizza più del 5% delle 
risorse vale lo stesso ragionamento espresso sopra: apriamo tutto e ci 
accontentiamo di vedere il tutto rallentato?


Sul geocoder mi vede completamente d’accordo: è pessimo! Un paio di 
settimane fa in lista ci sono state lamentazioni a riguardo “squalifica 
il progetto OSM” e così via. Ovviamente nessuno pensa che questo 
importante progetto è portato avanti principalmente da 2 persone 
https://github.com/openstreetmap/Nominatim/graphs/contributors E quindi 
la soluzione sarebbe molto semplice: contribuire al progetto!


Personalmente la moderazione la vedo come un rallentare i contributi. 
Recentemente OSM a Genova ha acquisito un ottimo ed esperto contributore 
che era stufo di aspettare settimane per vedere i propri contributi 
accettati da una mappa proprietaria a cui contribuiva. Posso essere 
d’accordo sullo studiare un sistema per alcune caratteristiche (leggasi 
linee di costa o confini) ma, almeno allo stato attuale una moderazione 
per qualsiasi contributo la vedo molto male.


Mi trovo d’accordo con la parte dei doppi ruoli degli oggetti, il 
classico caso di strade e fiumi che condividono un confine o un landuse 
mi hanno reso furibondo più di una volta per semplici operazioni di 
editing, immagino quale difficoltà comporti sviluppare strumenti che 
debbano tenere in considerazione anche queste eventualità.
E per rimanere sui temi più significativi sono anche d’accordo nel 
pensare che le API sono ferme alla versione 0.6 dal 2009.


Stavo aggiungendo un capitolo con considerazioni sull’Italia, ma 
rileggendolo non ho avuto il cuore di postarlo, almeno il giorno dopo la 
chiusura di FOSS4G-IT dove abbiamo visto quanto i dati OSM siano utili e 
utilizzati.


Alessandro Ale_Zena_IT

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

Re: [Talk-cz] oznacovani dlazdic jako dirty

[Miroslav Suchy]

Dne 23.2.2018 v 14:25 Petr Vozdecký napsal(a):
> Ahoj,
> 
> toto mi dříve spolehlivě fungovalo, dnes jsem to zkusil reinkarnovat a bez 
> úspěchu...
> 
> jinými slovy - jak jednoduše označit dlaždici jako dirty?

Spise me to prijde, jako ze je ted dlouha fronta.

Pred 2 dny jsem na re-render dlazdice cekal celou noc.

Mirek


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

Re: [Talk-cz] oznacovani dlazdic jako dirty

[majka]

Momentálně nejsnadněji přes JOSM. Je nutné mít zobrazenou vrstvu mapniku, a
pak se dlaždice dá označit jako dirty z mapy (Get tile status - získej
stav/ Force tile rendering - označit jako dirty).

2018-02-23 14:25 GMT+01:00 Petr Vozdecký :

> Ahoj,
>
> toto mi dříve spolehlivě fungovalo, dnes jsem to zkusil reinkarnovat a bez
> úspěchu...
>
> jinými slovy - jak jednoduše označit dlaždici jako dirty?
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] oznacovani dlazdic jako dirty

[Petr Vozdecký]

Ahoj,

toto mi dříve spolehlivě fungovalo, dnes jsem to zkusil reinkarnovat a bez
úspěchu...

jinými slovy - jak jednoduše označit dlaždici jako dirty?

vop
-- Původní e-mail --
Od: Petr Holub 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 28. 4. 2015 18:13:14
Předmět: [Talk-cz] oznacovani dlazdic jako dirty
"Ahoj,

narazil jsem na takovy docela pekny Greasemonkey skriptik, treba
se to bude nekomu hodit:
https://gist.github.com/Adrianod/e6b522bf1715a49b68c2
na Alt klik to pak umi na OSM invalidovat dlazdice.

Protoze jsme narazil na obcasne problemy se synchronizaci jednotlivych
tile serveru OSM, trochu jsem ho pro sichr osklive hacknul, ze to
jde po vsech serverech najednou, vizte nize.

Petr



// ==UserScript==

// @name click n' dirt
// @namespace https://gist.github.com/Adrianod/e6b522bf1715a49b68c2
// @description Alt-click to mark tiles as dirty on openstreetmap.org
// @include http://www.openstreetmap.org/*
// @include https://www.openstreetmap.org/*
// @version 1
// @grant none
// ==/UserScript==

/*
$.ajax({\
url: this.src.text().replace(/.\.tile\.openstreetmap\.org/, "a.tile.
openstreetmap.org")+"/dirty",\
context: this\
});\
*/

var code = '\
$("#map").on("click", ".leaflet-tile", function(e) {\
if (e.altKey) {\
$.ajax({\
url: this.src.replace(/.\.tile\.openstreetmap\.org/, "a.tile.openstreetmap.
org")+"/dirty",\
context: this\
}).done(function() {\
$(this).fadeTo("fast", .8);\
});\
$.ajax({\
url: this.src.replace(/.\.tile\.openstreetmap\.org/, "b.tile.openstreetmap.
org")+"/dirty",\
context: this\
}).done(function() {\
$(this).fadeTo("fast", .6);\
});\
$.ajax({\
url: this.src.replace(/.\.tile\.openstreetmap\.org/, "c.tile.openstreetmap.
org")+"/dirty",\
context: this\
}).done(function() {\
$(this).fadeTo("fast", .2);\
});\
}\
});';

var script = document.createElement("script");
script.textContent = code;
document.body.appendChild(script);



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

Re: [Talk-es] Calles muy estrechas

[Jose Luis Infante]

 Hola,

realmente el tema de que una calle sea estrecha es subjetivo. Puede ser
estrecha para un coche, para una moto, o para un peatón, o para una persona
en silla de ruedas. Para todas estas circunstancias hay etiquetas para
indicar esa información, incluso indicando el ancho real de la vía.

Otro tema es el de la clasificación de la vía en residential, pedestrian o
living_street. Aquí los criterios pueden variar. En mi opinión, si una vía
tiene nombre (indiferentemente que se llame callejón, trasera o avenida),
elijo una de las tres. Normalmente designo como residential aquella que
pueden circular vehículos, living_street en la que los peatones tienen
prioridad pero se permite la circulación general de vehículos (y comparten
la misma plataforma) y pedestrian aquella en las que solamente pueden
circular peatones con alguna excepción que permita el paso de vehículos
puntualmente.

En el caso de las calles estrechas del núcleo de un pueblo o ciudad,
escogería living_street o pedestrian, según la circunstancia. Normalmente
eligo living_street si pueden circular coches y motos (y se puede añadir la
etiqueta lanes), y pedestrian si su acceso está restringido. En un pueblo,
donde no creo que esté indicado esto para cada calle, aunque si que puede
ser que esté indicado para todo el núcleo. También la señalización viaria
puede servir de guía para la clasificación (sentido de la vía, cedas,
stops, etc). Yo optaría por indicar esas calles como pedestrian, sobretodo
en núcleos muy antiguos, donde la superficie de la vía no es la adecuada
para vehículos (piedra, etc) y pueden existir escalones. Además, una calle
puede ser tan estrecha que no pueda circular una moto o que si puede
circular ocupe todo el ancho de la vía, por lo que mejor ponerla como
pedestrian.

Nunca usaría un highway=service para una calle con nombre oficial, sino
simplemente para lo que se indica. Lo usaría para indicar el callejón de
servicio de algún establecimiento, para el acceso y vías internas de una
propiedad o instalación o para la vía de carga y descarga de una empresa.

Tampoco usaría highway=footway para indicar la vía principal de una calle.
Si que la uso para indicar aceras, caminos o senderos.

No se ha mencionado, pero está el uso de highway=steps. En el tema que
estamos hablando, yo lo uso de forma dual. Lo uso para indicar unas
escaleras dentro de un parque o un recinto, o como un footway (una acera,
p.e.) donde hay escalones. En otros casos lo he usado como si fuera un
pedestrian, indicando la vía principal de calle, es decir, informando el
nombre de la vía.

Un saludo,

Jose Luis

PD:
En resumen, para vías urbanas:
Hay una plataforma para vehículos y otra, si la hay, para peatones
(aceras): residential
Se comparte la misma plataforma:
- Los vehículos pueden circular de forma general, pero con restricciones de
acceso, peso, velocidad, etc o expresamente está señalizado: living_street
- No pueden circular vehículos por la fisinomía de la vía o porque existe
señalización o bolardos o similares, exceptuando circunstancias
particulares: pedestrian
- Hay escaleras: steps


El 23 de febrero de 2018, 14:00, dcapillae  escribió:

> Hola, Jesús.
>
> En la documentación de la etiqueta «highway=residential» se dice que se
> trata de «carreteras que dan acceso o pasan alrededor de áreas
> residenciales» o calles utilizadas «generalmente sólo para el tráfico local
> por personas que viven dentro del asentamiento» [1].
>
> Un calle estrecha de pueblo donde no entra un coche y, por tanto, no hay
> tráfico local, no encaja en esa categoría de vías. Probablemente podamos
> decir que esas calles siguen siendo residenciales, ya que efectivamente van
> a ser usadas preferentemente sólo por personas residentes en la zona. Estoy
> de acuerdo. Pero no se trata tanto de calificarlas como «residenciales»
> como
> de considerar qué etiqueta describe mejor el tipo de vía.
>
> En mi opinión, la etiqueta «highway=residential» se refiere a otra cosa, a
> un tipo de vía distinto al que nos estamos refiriendo. No describe el tipo
> de calle estrecha, enrevesada, preferentemente peatonales, a veces con
> tramos de escaleras y desniveles, sin tráfico propiamente dicho y donde
> físicamente no entra un coche. Calles como las que podemos encontrar, por
> ejemplo, en la parte antigua de muchos pueblos andaluces.
>
> Lógicamente el pueblo tendrá sus calles de tipo «highway=residential», como
> cualquier núcleo de población al que se pueda acceder en coche, pero no
> todas las calles van a ser de ese tipo. Hay muchas calles estrechas que, en
> mi opinión, no son «highway=residential» aunque se las pueda considerar
> como
> residenciales.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=residential
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> 

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Philippe Verdy]

Le problème avec les changesets énormes, c'est la grosse demande de
ressource que cela demande d'un coup au serveur, et ensuite la difficulté
de repérer les erreurs et la lourdeur des "revert". Même si on peut mettre
5 objets, il vaut mieux éviter sauf si ce sont des noeuds uniquement
utilisés pour la géométrie des ways et  sans tags descriptifs (les tags
d'annotation sans valeur sémantique telle que note ou fixme ou source
peuvent être ignorés, de même que les tags marqués comme "à supprimer"), et
je dirais qu'il faudrait éviter d'avoir plus de 5000 objets tagués par
changeset (et c'est déjà énorme) ou plus 200 relations.

Pour les batchs d'envoi, régler aussi le batch pour qu'il envoie par paquet
de 50 objets maxi et non les 5000 d'un coup : en cas de conflit d'édition
ça limite énormément le travail de résolution des conflits et si on
abandonne parce qu'il y a trop de conflits à gérer, on laisse de gros
dégâts avec des objets inutiles ou non référencés ou incomplets (et c'est
galère ensuite à nettoyer). Mais là les préréglage de JOSM donnent une
limite de batch beaucoup trop grande. 50 objets c'est suffisant pour faire
de gros envois avec un temps de réponse très raisonnable du serveur sans de
trop nombreux ping-pongs ralentis par le réseau (même pour les envois de
très nombreux noeuds non tagués pour de nouveaux ways très précis), et ça
évite d'accaparer pour soi les ressources du serveur le temps que les
grosses requêtes se terminent dans leur transaction (ça permet de partager
les ressources disponibles).


Le 23 février 2018 à 12:31, Christian Quest  a
écrit :

> JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5
> objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets).
>
> Le problème n'est pas technique, mais plus sur le principe.
>
> Il y a des règles à respecter pour importer des données dans OSM:
> - légales (on commence par vérifier la compatibilité des licences, je
> pense qu'il n'y a pas de souci ici)
> - collaboratives: on documente et on discute de l'import avec les
> contributeurs locaux... pour vérifier le bien fondé de celui-ci, travailler
> en semble à traiter les défauts, incohérences, conflits, etc
> - techniques: on fait des tests, on valide la méthode, là encore pas tout
> seul dans son coin, avant de se lancer...
>
> Il serait préférable que tu prépares quelques cours d'eau et mette les
> fichiers .osm correspondants en partage pour validation avant d'uploader
> quoi que ce soit, surtout vue la première manip.
>
>
>
> Le 23 février 2018 à 11:26, Rpnpif  a écrit :
>
>> Le 22 février 2018, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> > Le 22/02/2018 à 17:15, marc marc - marc_marc_...@hotmail.com a écrit :
>> >
>> > > Bonjour,
>> > >
>> > > Le 22. 02. 18 à 16:48, Rpnpif a écrit :
>> > >> Je suis novice dans JOSM.
>> > >> https://www.openstreetmap.org/changeset/56579562
>> > >> Qu'en pensez-vous ?
>> > > J'annule et on repart de 0 ? :-)
>> > >
>> > > Cordialement,
>> > > Marc
>> > Je suis d'accord avec Marc, notamment la dernière proposition.
>> > Faire un import massif avec un outil que l'on ne connaît pas, faut être
>> > un peu gonflé ;-).
>> > J'ai pris un point au hasard
>> > https://www.openstreetmap.org/node/5429129253#map=17/47.67817/-0.94895
>> > Je vois que c'est à proximité immédiate de La Verzée.
>> > Sur le site indiqué c'est un point de La Verzée.
>> > Donc deux possibilités :
>> > - l'info est meilleure
>> > - l'info est moins bonne (décalée ou pire).
>> >
>> > Dans le second cas la solution est simple ;-)
>> > Dans le premier il faut importer le bout de ruisseau et remplacer le
>> > bout équivalent existant (pour ne pas perdre les attributs).
>> > Ce n'est pas une opération triviale : il faut bien connaître JOSM et
>> OSM.
>> > Donc à ne pas faire seule, cherche quelqu'un du côté de chez toi ou tu
>> > sauvegarde les modifications localement et tu demandes à quelqu'un sur
>> > la liste par exemple de vérifier.
>>
>> Bonjour,
>>
>> J'avais pris mes précautions et vérifier chaque nœud.
>> Quelques points étaient en doublon parce que mieux placés. J'ai effacé
>> dans JOSM tous ceux qui me semblaient apporter moins d'infos que ceux
>> qui existaient déjà. Sauf peut-être un ou deux ponts qui m'auraient
>> peut-être échappés sur La Verzée, je n'ai pas touché à cette rivière (ni
>> aux autres waterway=river) qui me semblaient bien tracée dans
>> l'ensemble. J'aurais ensuite revérifié et affiné directement sur la
>> carte en ligne. J'ai laissé des tracés d'origine qui me semblaient plus
>> précis sur la carte en ligne.
>>
>> Le but était d'abord et avant tout de placer les ruisseaux manquants.
>> Mais aucun way n'a été tranféré. J'ai encore le fichier d'origine qui
>> a été construit à l'aide d'un fichier SHP issu de la source qui est
>> fiable et relativement précise car vérifié progressivement sur le
>> terrain par les techniciens fonctionnaires. Il y des aspects légaux en
>> terme 

Re: [Talk-es] Calles muy estrechas

[dcapillae]

Hola, Jesús.

En la documentación de la etiqueta «highway=residential» se dice que se
trata de «carreteras que dan acceso o pasan alrededor de áreas
residenciales» o calles utilizadas «generalmente sólo para el tráfico local
por personas que viven dentro del asentamiento» [1].

Un calle estrecha de pueblo donde no entra un coche y, por tanto, no hay
tráfico local, no encaja en esa categoría de vías. Probablemente podamos
decir que esas calles siguen siendo residenciales, ya que efectivamente van
a ser usadas preferentemente sólo por personas residentes en la zona. Estoy
de acuerdo. Pero no se trata tanto de calificarlas como «residenciales» como
de considerar qué etiqueta describe mejor el tipo de vía.

En mi opinión, la etiqueta «highway=residential» se refiere a otra cosa, a
un tipo de vía distinto al que nos estamos refiriendo. No describe el tipo
de calle estrecha, enrevesada, preferentemente peatonales, a veces con
tramos de escaleras y desniveles, sin tráfico propiamente dicho y donde
físicamente no entra un coche. Calles como las que podemos encontrar, por
ejemplo, en la parte antigua de muchos pueblos andaluces.

Lógicamente el pueblo tendrá sus calles de tipo «highway=residential», como
cualquier núcleo de población al que se pueda acceder en coche, pero no
todas las calles van a ser de ese tipo. Hay muchas calles estrechas que, en
mi opinión, no son «highway=residential» aunque se las pueda considerar como
residenciales.

[1] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=residential



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Cascafico Giovanni]

Bene, la discussione è interessante ed ha rivelato una cosa palese: c'è un
mostruoso sbilanciamento di potere tra mappatori volontari ed una azienda
privata monopolistica dell'informazione globale.

Ora come ora, se un vandalo di OSM causa la morte di una persona perchè ha
cambiato il nome della via, nessuno lo perseguirà. Cosa che invece si
paventa a chi riporta di aver visto una incoerenza sullo schermo di un PC.

Il panorama è desolante.




Il giorno 23 febbraio 2018 11:34, Simone Saviolo 
ha scritto:

> Il giorno 23 febbraio 2018 09:40, Fra Mauro  ha
> scritto:
>
>> Scusate se mi permetto, ma a me sembra che su questa discussione si
>> mischino molti più piani.
>>
>> - cosa dice la licenza di dati e foto secondo Google. La cosa è
>> importante per capire tra l'altro in qualche modo la probabilità di essere
>> denunciato
>> - cosa dice la licenza dei dati secondo un giudice competente. È chiaro
>> che Google, da privato, ha interesse a lasciare intendere che la copertura
>> della licenza sia il più ampia possibile
>> - quali sono i rischi legali che corre OMS/un mappatore. Come detto da
>> qualcuno di voi, uno può pensare che è potenzialmente esposto ad una accusa
>> anche NON copiando da Google. Allo stesso tempo, qualcuno ha evidenziato
>> che SCRIVERE di copiare da Google aumenta drasticamente i rischi.
>> - quali sono gli aspetti "etici". È moralmente giusto copiare da Google.
>> Come definisco copiare da un punto di vista morale...
>> - l'impatto di copiare da Google da un punto di vista della qualità. I
>> dati di Google (foto comprese) sono di qualità minore di quanto possa
>> sembrare (esempio del limite di velocità francese)
>>
>> A me sembra evidente che nel caso di partenza (utente che SCRIVE sul
>> proprio diario che tra le sue fonti c'è Google) si ha:
>> - Google pensa che è contro licenza
>> - un giudice pensa che è contro licenza
>> - il rischio legale è altro
>> - il comportamento sia eticamente discutibile per parecchie persone
>>
>> Se poi avete fatto mappatura su strada, con foto su cellulare e a casa
>> verificate se la lettera dell'insegna che è un po' sfocata in foto sia "a"
>> oppure "e"... il rischio legale è sostanzialmente nullo e la vostra etica
>> personale vi dirà se è giusto o meno.
>>
>> È però importante ricordare che alla fine in caso di processo non sarà la
>> vostra etica personale a contare, l'importante è quello che decide il
>> giudice!!!
>>
>
> Pienamente d'accordo.
>
> Ciao,
>
> Simone
>
> ___
> 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-ec] Mejoras a la red de carreteras en Ecuador

[Julio Martinez]

Muchas Gracias Daniel, no puedo estar más de acuerdo con tus comentarios.

Saludos




On 22/02/18 17:34, Daniel Orellana wrote:

Gracias Andrew por tu pronta respuesta!

En las calles mencionadas (Sucre y Bolivar) la tipología es la misma 
que todas las calles del sector, con un solo sentido de circulación. 
La jerarquía de las calles no se determina en función de la cantidad 
de tráfico (que es variable) y menos aún con los datos de una fuente 
como STRAVA que tiene un sesgo socioeconómico muy fuerte y está 
principalmente orientada a actividades deportivas.


He seguido encontrando otros ejemplos donde se ha degradado de vías 
secundarias a terciarias en Cuenca.
https://www.openstreetmap.org/way/46227733/history 



Por favor tengan en cuenta que ha tomado mucho tiempo lograr tener un 
acuerdo sobre las etiquetas e implementarlas en diversas ciudades. 
Este tipo de cambios deben ser siempre consultados con la comunidad. 
El conocimiento local es el más útil en OpenStreetMap. El objetivo de 
todos es tener un mapa lo más parecido posible a la realidad y eso se 
logra principalmente con el conocimiento de las personas que viven en 
el lugar. Realmente estamos contentos que Apple y TELNAV cualquier 
otra empresa pueda apoyar para mejorar el mapa, pero es imprescindible 
que se incluya a la comunidad local en estos cambios. Sobre todo en 
lugares bien mapeados, es ilógico que se cambien atributos de vías que 
ya han pasado por varios procesos de discusión.


Por el momento te rogaría que reviertan todos los cambios de 
jerarquías de vías que ha hecho el equipo de Apple en la ciudad de 
Cuenca (nosotros validamos estas etiquetas hace más de un año). Así 
mismo recomiendo que en los cambios futuros consulten a la comunidad o 
coloquen avisos de revisión para que usuarios con conocimiento local 
las validen.


Creo que su colaboración puede centrarse en otros esfuerzos: por 
ejemplo en ciudades o zonas rurales donde que no están mapeadas, 
corregir errores topoloógicos,  utilizar los algoritmos desarrollados 
para extraer los footprints de los edificios,  incorporar información 
de POIs a partir de sus bases de datos, etc.


Muchas gracias por tu comprensión y espero que podamos seguir colaborando.


___
Daniel Orellana, PhD.
Profesor Principal
Universidad de Cuenca

>> Consulta mi agenda 

>> Publicaciones en Google Scholar 

>> Perfil en ResearchGate 


>> Investigación en LlactaLAB 
>> Investigación en iDRHICA 



2018-02-22 16:32 GMT-05:00 Andrew Wiseman >:


Hola Daniel,

Gracias por su mensaje. Podemos cambiarlos pero tengo una pregunta
sobre el primero ejemplo: el wiki de normalización dice que
tertiary es "Avenidas urbanas pequeñas / Calles grandes” y "Sin
separación entre sentidos de circulación, con un carril por cada
sentido de circulación. Más importantes que las calles normales.”
Calles Sucre y Simón Bolívar tienen más tráfico por Strava GPS, y
por eso me parece que son más importantes que las calles normales.
Una captura de pantalla de JOSM:

Por favor déjame saber lo que piensas.




Saludos,

Andrew

Andrew Wiseman |Maps | andrew_wise...@apple.com


APPLE CONFIDENTIAL
This message (including attachments if any) is for the private use
of the addressee only and may contain confidential or privileged
information. If you have received this message by mistake please
notify the sender by return e-mail and delete this message and any
attachments from your system. Any unauthorized use or
dissemination of this message, and any attachments in whole or in
part is strictly prohibited.





On Feb 22, 2018, at 8:01 AM, Daniel Orellana
> wrote:

Hola Andrew.

Te comento que hemos encontrado algunos problemas en las
ediciones que está haciendo tu equipo, en particular el usuario
TyFly. He detectado que varias calles en la ciudad de Cuenca se
han cambiado las etiquetas injustificadamente

Ej 1: Calle sucre es residential y se ha cambiado a tertiary
https://www.openstreetmap.org/way/337277984


Ej 2: Calle Roberto Crespo Toral es Secondary y se ha cambiado a
tertiary.
https://www.openstreetmap.org/way/42143234


Por favor indica a tu equipo que revierta estos cambios y que
consulte acá antes de realizar este tipo de cambios ya que nos ha
costado 

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Christoph Hormann]

On Friday 23 February 2018, Rory McCann wrote:
>
> But then how far do you go? Should every stream be connected to the
> central river? e.g. what about here (
> http://tools.geofabrik.de/osmi/?view=water=28.57869=-16.75136
>=11 )?
>
> If some rivers/streams shouldn't be connected, then some data
> consumers will have to do an automatic connection anyway. When
> measuring water run off and pollution, you probably want to know that
> "stuff going into stream X will eventually get to point Y downstream"
> (right?).

For simple formal connectivity that is essentially a routing problem.  
Not having connectivity on the waterway level will require you to use 
the water area data in analysis and this will more than double the data 
volume to process and if you need more than formal connectivity, i.e. 
quantitative information like path length or route geometry things 
become very expensive computationally.

> Connecting all means that large lakes will be full of a "skeleton" of
> joining rivers/streams, and a small 1km stream could get a lot
> longer.

You could detect the 'virtual' waterways as those within a non-river 
water area.  This is hampered by the problem that we mostly have no 
consistent distinction between river and lake areas in OSM (i.e. 
standing and flowing water areas).

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

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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Christian Quest]

JOSM n'est pas limité à 1 noeuds. Un changeset est limité à 5
objets et JOSM sait gérer ça (mon upload record c'est 400.000 objets).

Le problème n'est pas technique, mais plus sur le principe.

Il y a des règles à respecter pour importer des données dans OSM:
- légales (on commence par vérifier la compatibilité des licences, je pense
qu'il n'y a pas de souci ici)
- collaboratives: on documente et on discute de l'import avec les
contributeurs locaux... pour vérifier le bien fondé de celui-ci, travailler
en semble à traiter les défauts, incohérences, conflits, etc
- techniques: on fait des tests, on valide la méthode, là encore pas tout
seul dans son coin, avant de se lancer...

Il serait préférable que tu prépares quelques cours d'eau et mette les
fichiers .osm correspondants en partage pour validation avant d'uploader
quoi que ce soit, surtout vue la première manip.



Le 23 février 2018 à 11:26, Rpnpif  a écrit :

> Le 22 février 2018, osm.sanspourr...@spamgourmet.com a écrit :
>
> > Le 22/02/2018 à 17:15, marc marc - marc_marc_...@hotmail.com a écrit :
> >
> > > Bonjour,
> > >
> > > Le 22. 02. 18 à 16:48, Rpnpif a écrit :
> > >> Je suis novice dans JOSM.
> > >> https://www.openstreetmap.org/changeset/56579562
> > >> Qu'en pensez-vous ?
> > > J'annule et on repart de 0 ? :-)
> > >
> > > Cordialement,
> > > Marc
> > Je suis d'accord avec Marc, notamment la dernière proposition.
> > Faire un import massif avec un outil que l'on ne connaît pas, faut être
> > un peu gonflé ;-).
> > J'ai pris un point au hasard
> > https://www.openstreetmap.org/node/5429129253#map=17/47.67817/-0.94895
> > Je vois que c'est à proximité immédiate de La Verzée.
> > Sur le site indiqué c'est un point de La Verzée.
> > Donc deux possibilités :
> > - l'info est meilleure
> > - l'info est moins bonne (décalée ou pire).
> >
> > Dans le second cas la solution est simple ;-)
> > Dans le premier il faut importer le bout de ruisseau et remplacer le
> > bout équivalent existant (pour ne pas perdre les attributs).
> > Ce n'est pas une opération triviale : il faut bien connaître JOSM et OSM.
> > Donc à ne pas faire seule, cherche quelqu'un du côté de chez toi ou tu
> > sauvegarde les modifications localement et tu demandes à quelqu'un sur
> > la liste par exemple de vérifier.
>
> Bonjour,
>
> J'avais pris mes précautions et vérifier chaque nœud.
> Quelques points étaient en doublon parce que mieux placés. J'ai effacé
> dans JOSM tous ceux qui me semblaient apporter moins d'infos que ceux
> qui existaient déjà. Sauf peut-être un ou deux ponts qui m'auraient
> peut-être échappés sur La Verzée, je n'ai pas touché à cette rivière (ni
> aux autres waterway=river) qui me semblaient bien tracée dans
> l'ensemble. J'aurais ensuite revérifié et affiné directement sur la
> carte en ligne. J'ai laissé des tracés d'origine qui me semblaient plus
> précis sur la carte en ligne.
>
> Le but était d'abord et avant tout de placer les ruisseaux manquants.
> Mais aucun way n'a été tranféré. J'ai encore le fichier d'origine qui
> a été construit à l'aide d'un fichier SHP issu de la source qui est
> fiable et relativement précise car vérifié progressivement sur le
> terrain par les techniciens fonctionnaires. Il y des aspects légaux en
> terme d'agriculture par exemple, derrière leur démarche.
>
> J'ai bien noté ce que recommande Marc Marc à propos de l'attribut
> sources. Mais dans ce cas où doit-on mettre le source dans JOSM ?
> Je ne savais pas que JOSM était limité à 1 nœuds (où trouve t-on
> cette valeur ?). J'avais pourtant choisi une zone qui me semblait très
> limitée par rapport à l'objectif. Il faudra que je le fasse à l'avenir
> par tranche plus fine.
>
> > J'annule et on repart de 0 ? :-)
> C'est-à-dire ?
>
> Puis-je refaire un essai avec un seul ruisseau ?
>
> Cordialement.
> --
> Alain Rpnpif
>
> ___
> 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-es] Calles muy estrechas

[Luis García Castro]

Buenas,

No me sonaban bien algunas cosas que se han dicho y he revisado un poco.
Creo que la descripción de «service=alley» (usada con «highway=service»)
que aparece en la wiki es exactamente lo que queremos describir con esas
calles estrechas de pueblo:

In some medieval (European) settlements alleys may be the very narrow
streets which run in-between buildings, providing public through-access.

If a narrow street is prohibited for motor vehicles, consider using highway
=footway
 or highway
=pedestrian
.

Yo sólo usaría  «highway=footway» como ellos dicen, cuando es realmente un
paso prohibido para vehículos.

¿Qué os parece?

El 23 de febrero de 2018, 12:13, Javier Sánchez Portero <
javiers...@gmail.com> escribió:

> Yo no. No se trata del ancho, sólo, sino de establecer una clasificación
> entre distintos tipos de calles lo mismo que hay primary/secondary/tertiary
> pista carreteras.
>
> Si el nombre es callejón, pasaje, transversal y variantes son pistas de
> este tipo de vías
> https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley
>
>
> El 23 feb. 2018 10:25, "Jesús Lopez"  escribió:
>
>> Buenos días.
>>
>> Estoy de acuerdo con Rafael. Pienso que la calle es residencial sin
>> depender de su ancho. Si es demasiado estrecha y no permite el paso de
>> algún tipo de vehículo siempre se puede añadir algún tipo de restricción al
>> vial [1].
>>
>> Saludos
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:access
>>
>>
>> > El 23 feb 2018, a las 01:29, Rafael Avila Coya 
>> escribió:
>> >
>> > Hola, Daniel:
>> >
>> > Naturalmente, mapeamos lo que es correcto, nunca para el renderizador ;)
>> >
>> > En mi opinión, una calle puede ser residencial aún cuando no puedan
>> pasar coches, pues es posible que el tránsito de motos siga siendo posible
>> y permitido.
>> >
>> > Un saludo,
>> >
>> > Rafael.
>> >
>> > [1] https://www.openstreetmap.org/#map=18/40.41762/-3.68265
>> >
>> > On 23/02/18 00:17, dcapillae wrote:
>> >> Estos días estoy revisando el callejero de los pueblos de Málaga para
>> >> preparar la importación de edificios y direcciones del Catastro [1], y
>> he
>> >> podido comprobar que muchas calles estrechas de los pueblos de Málaga,
>> de
>> >> uso fundamentalmente peatonal y por donde no pasa un coche, están
>> mapeadas
>> >> como «highway=residential».
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>


-- 

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

Re: [Talk-es] Calles muy estrechas

[Javier Sánchez Portero]

Yo no. No se trata del ancho, sólo, sino de establecer una clasificación
entre distintos tipos de calles lo mismo que hay primary/secondary/tertiary
pista carreteras.

Si el nombre es callejón, pasaje, transversal y variantes son pistas de
este tipo de vías
https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley


El 23 feb. 2018 10:25, "Jesús Lopez"  escribió:

> Buenos días.
>
> Estoy de acuerdo con Rafael. Pienso que la calle es residencial sin
> depender de su ancho. Si es demasiado estrecha y no permite el paso de
> algún tipo de vehículo siempre se puede añadir algún tipo de restricción al
> vial [1].
>
> Saludos
>
> [1] https://wiki.openstreetmap.org/wiki/Key:access
>
>
> > El 23 feb 2018, a las 01:29, Rafael Avila Coya 
> escribió:
> >
> > Hola, Daniel:
> >
> > Naturalmente, mapeamos lo que es correcto, nunca para el renderizador ;)
> >
> > En mi opinión, una calle puede ser residencial aún cuando no puedan
> pasar coches, pues es posible que el tránsito de motos siga siendo posible
> y permitido.
> >
> > Un saludo,
> >
> > Rafael.
> >
> > [1] https://www.openstreetmap.org/#map=18/40.41762/-3.68265
> >
> > On 23/02/18 00:17, dcapillae wrote:
> >> Estos días estoy revisando el callejero de los pueblos de Málaga para
> >> preparar la importación de edificios y direcciones del Catastro [1], y
> he
> >> podido comprobar que muchas calles estrechas de los pueblos de Málaga,
> de
> >> uso fundamentalmente peatonal y por donde no pasa un coche, están
> mapeadas
> >> como «highway=residential».
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Maarten Deen]

On 2018-02-23 11:35, Rory McCann wrote:

On 23/02/18 06:53, Maarten Deen wrote:
I see nothing wrong with those examples, I would do it the same, 
especially if the rivers can be sailed on by boat. Then you absolutely 
need the rivers to be connected to a central river (or fairway) in the 
lake.


But then how far do you go? Should every stream be connected to the
central river? e.g. what about here (
http://tools.geofabrik.de/osmi/?view=water=28.57869=-16.75136=11
)?


Mappers discretion. I'm not advocating a "must" in this case. I'm saying 
it's not a bad thing if it is done and in some circumstances it is 
preferrable.
See it as roads connecting to a square. As long as routing over areas is 
not commonplace it is acceptable and even preferrable to lay roads over 
the square.



If some rivers/streams shouldn't be connected, then some data consumers
will have to do an automatic connection anyway. When measuring water 
run

off and pollution, you probably want to know that "stuff going into
stream X will eventually get to point Y downstream" (right?).


Yes. OSM gets used (maybe misused) for all kinds of purposes, but a 
hydrological analysis would be impossible if streams that are physically 
connected are not so in OSM.



Connecting all means that large lakes will be full of a "skeleton" of
joining rivers/streams, and a small 1km stream could get a lot longer.


Good point, but can be solved by using relations for the streams and not 
including the part of the stream that runs through the lake. In any 
case, I would think it strange to still use the the name of the stream 
on the part that runs through the lake.


Maarten

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

Re: [Talk-it] Josm off line, come salvare la visione aerea

[Alberto Nogaro]

Ciao,



un metodo, un po’ contorto ma comodo, per riempire automaticamente la cache con 
le tiles delle immagini sulla zona in cui lavori può essere questo:



*   apri una copia del layer dati per cui vuoi salvare la visione aerea, 
diciamo che si chiami “Pippo”
*   nella finestra “Layers”, clicca con il tasto destro su “Pippo” e 
seleziona la voce “Convert to GPX layer”
*   ti comparira un layer gpx nominato “Converted from: Pippo”
*   apri il  livello di immagini che ti interessa, nel tuo caso Bing
*   zooma fino ad un livello utile per vedere bene le immagini
*   nella finestra “Layers”, clicca con il tasto destro su “Converted from: 
Pippo” e seleziona la voce “Precache imagery tiles along this track” e poi su 
“Download”
*   al termine del download, tutte le tile immagine della zona compresa nel 
tuo layer dati saranno state salvate al livello di zoom corrente



Ora le immagini dovrebbero essere disponibili anche quando sei off line



Ciao,

Alberto









From: riccardopastoc...@alice.it [mailto:riccardopastoc...@alice.it]
Sent: venerdì 23 febbraio 2018 09:22
To: talk-it@openstreetmap.org
Subject: [Talk-it] Josm off line, come salvare la visione aerea



Buon giorno,

spesso mi trovo a mappare in modalità off line, cioè dalla stanzetta autisti 
del 118 dove non abbiamo internet.



Ma non riesco a capire come salvarmi la cartina con la visione aerea (es Bing) 
da sovrascrivere a Josm.



Descrivo il mio procedimento, in modo che possiate capire l'errore.



1) Da casa in modalità on line, mi apro Josm seleziono l'area di lavoro e 
salvo: file_salva come_   "data+ora" .osm

e fin qui tutto bene perchè quando vado in modalità off line, mi riapro il file 
e tutto funziona;

tranne il fatto che mi salva solo il file josm, quindi le linee che traccio 
io,ma non il livello di Bing (modalità aerea).



2) allora ho provato a salvare il livello Bing con estensione WMS  (Web Map 
Service), e succede che al al primo riavvio del Pc riesco ad aprire anche la 
mappa Aerea,

ma se spengo e riaccendo il Pc, non mi apre più il file di Bing, o meglio me lo 
apre ma mi fa schermo nero  con scritte "nessun tassello in questo livello di 
ingrandimento".



3) provando a "spippolare" tra sottocartelle e file adesso non riesco a far 
riaprire il livello di Bing neanche al primo riavvio







Chiedo gentilmente di utilizzare terminologia consona ad un principiante, grazie



Riccardo Pastocchi







---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[François Lacombe]

 (Sorry Rory, resent this to Talk ML)

2018-02-23 11:35 GMT+01:00 Rory McCann :

> On 23/02/18 06:53, Maarten Deen wrote:
>
>> I see nothing wrong with those examples, I would do it the same,
>> especially if the rivers can be sailed on by boat. Then you absolutely need
>> the rivers to be connected to a central river (or fairway) in the lake.
>>
>
> But then how far do you go? Should every stream be connected to the
> central river? e.g. what about here ( http://tools.geofabrik.de/osmi
> /?view=water=28.57869=-16.75136=11 )?
>

Yes: http://tools.geofabrik.de/osmi/?view=water=28.57869;
lat=-16.75136=11


> If some rivers/streams shouldn't be connected, then some data consumers
> will have to do an automatic connection anyway. When measuring water run
> off and pollution, you probably want to know that "stuff going into
> stream X will eventually get to point Y downstream" (right?).
>

I don't get this, which situation do you think of when you say " If some
rivers/streams shouldn't be connected " ?


> Connecting all means that large lakes will be full of a "skeleton" of
> joining rivers/streams, and a small 1km stream could get a lot longer.

Yes they do http://tools.geofabrik.de/osmi/?view=water=28.57869;
lat=-16.75136=11

This can be solved by removing waterways sections which intersect with
lakes water body.
It could be done on consumer purpose for a particular usage.
Topology is also a really useful data and waterways should definetly
connect downstream sections.

2018-02-23 11:45 GMT+01:00 Joseph Reeves :

> Slightly off topic, but I was recently wondering if there was a waterway
> routing tool available? As in, I'd like to click a point in a waterway and
> have the downstream route plotted, presumably to the sea. It appears to me
> that a tool like that could be useful in this discussion?
>

You can achieve this with OSRM with a proper routing profile, or even
pg-routing if you are at ease with it.

All the best

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

Re: [OSM-talk] Is this legal to what philly.com is doing?

[James]

specifically:
http://philly.reprintmint.com/006-default.html?src=http%3A%2F%2Fmedia.philly.com%2Fimages%2F250*250%2Fdixon-390888-f-wp-content-uploads-2018-02-dixon-384405-e-wp-content-uploads-2018-02-new-map-1200x800.png=http%3A%2F%2Fmedia.philly.com%2Fimages%2Fdixon-390888-f-wp-content-uploads-2018-02-dixon-384405-e-wp-content-uploads-2018-02-new-map-1200x800.png=006=dixon-384405-e-wp-content-uploads-2018-02-new-map=The%20new%20congressional%20map%20released%20Monday%20by%20the%20Pennsylvania%20Supreme%20Court
.

On Feb 22, 2018 11:06 PM, "James Mast"  wrote:

> http://www.philly.com/philly/news/politics/will-republicans-impeach-
> pennsylvania-supreme-court-justices-20180222.html
>
> (ignore what the article is about)
>
>
> Just happen to see a thumbnail and clicked on the article since I noticed
> the OSM base map.  Nowhere that I can find does it give credit to OSM for
> the use of it.
>
>
> Now, the part to where I was curious if this was legal (sans the lack of
> credit), is that they are 'selling' the uploaded image.  Is that allowed
> currently under the license that OSM has?
>
>
> Just thought I'd throw this out there for somebody more experienced in
> this sector.
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Joseph Reeves]

Hi all,

Slightly off topic, but I was recently wondering if there was a waterway
routing tool available? As in, I'd like to click a point in a waterway and
have the downstream route plotted, presumably to the sea. It appears to me
that a tool like that could be useful in this discussion?

Despite my best efforts, I keep finding river drainage basins fascinating :)

Cheers, Joseph



On 23 February 2018 at 10:35, Rory McCann  wrote:

> On 23/02/18 06:53, Maarten Deen wrote:
>
>> I see nothing wrong with those examples, I would do it the same,
>> especially if the rivers can be sailed on by boat. Then you absolutely need
>> the rivers to be connected to a central river (or fairway) in the lake.
>>
>
> But then how far do you go? Should every stream be connected to the
> central river? e.g. what about here ( http://tools.geofabrik.de/osmi
> /?view=water=28.57869=-16.75136=11 )?
>
> If some rivers/streams shouldn't be connected, then some data consumers
> will have to do an automatic connection anyway. When measuring water run
> off and pollution, you probably want to know that "stuff going into
> stream X will eventually get to point Y downstream" (right?).
>
> Connecting all means that large lakes will be full of a "skeleton" of
> joining rivers/streams, and a small 1km stream could get a lot longer.
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Rory McCann]

On 23/02/18 06:53, Maarten Deen wrote:
I see nothing wrong with those examples, I would do it the same, 
especially if the rivers can be sailed on by boat. Then you absolutely 
need the rivers to be connected to a central river (or fairway) in the 
lake.


But then how far do you go? Should every stream be connected to the
central river? e.g. what about here ( 
http://tools.geofabrik.de/osmi/?view=water=28.57869=-16.75136=11 
)?


If some rivers/streams shouldn't be connected, then some data consumers
will have to do an automatic connection anyway. When measuring water run
off and pollution, you probably want to know that "stuff going into
stream X will eventually get to point Y downstream" (right?).

Connecting all means that large lakes will be full of a "skeleton" of
joining rivers/streams, and a small 1km stream could get a lot longer.


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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Simone Saviolo]

Il giorno 23 febbraio 2018 09:40, Fra Mauro  ha
scritto:

> Scusate se mi permetto, ma a me sembra che su questa discussione si
> mischino molti più piani.
>
> - cosa dice la licenza di dati e foto secondo Google. La cosa è importante
> per capire tra l'altro in qualche modo la probabilità di essere denunciato
> - cosa dice la licenza dei dati secondo un giudice competente. È chiaro
> che Google, da privato, ha interesse a lasciare intendere che la copertura
> della licenza sia il più ampia possibile
> - quali sono i rischi legali che corre OMS/un mappatore. Come detto da
> qualcuno di voi, uno può pensare che è potenzialmente esposto ad una accusa
> anche NON copiando da Google. Allo stesso tempo, qualcuno ha evidenziato
> che SCRIVERE di copiare da Google aumenta drasticamente i rischi.
> - quali sono gli aspetti "etici". È moralmente giusto copiare da Google.
> Come definisco copiare da un punto di vista morale...
> - l'impatto di copiare da Google da un punto di vista della qualità. I
> dati di Google (foto comprese) sono di qualità minore di quanto possa
> sembrare (esempio del limite di velocità francese)
>
> A me sembra evidente che nel caso di partenza (utente che SCRIVE sul
> proprio diario che tra le sue fonti c'è Google) si ha:
> - Google pensa che è contro licenza
> - un giudice pensa che è contro licenza
> - il rischio legale è altro
> - il comportamento sia eticamente discutibile per parecchie persone
>
> Se poi avete fatto mappatura su strada, con foto su cellulare e a casa
> verificate se la lettera dell'insegna che è un po' sfocata in foto sia "a"
> oppure "e"... il rischio legale è sostanzialmente nullo e la vostra etica
> personale vi dirà se è giusto o meno.
>
> È però importante ricordare che alla fine in caso di processo non sarà la
> vostra etica personale a contare, l'importante è quello che decide il
> giudice!!!
>

Pienamente d'accordo.

Ciao,

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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Rpnpif]

Le 22 février 2018, osm.sanspourr...@spamgourmet.com a écrit :

> Le 22/02/2018 à 17:15, marc marc - marc_marc_...@hotmail.com a écrit :
> 
> > Bonjour,
> >
> > Le 22. 02. 18 à 16:48, Rpnpif a écrit :  
> >> Je suis novice dans JOSM.
> >> https://www.openstreetmap.org/changeset/56579562
> >> Qu'en pensez-vous ?  
> > J'annule et on repart de 0 ? :-)
> >
> > Cordialement,
> > Marc  
> Je suis d'accord avec Marc, notamment la dernière proposition.
> Faire un import massif avec un outil que l'on ne connaît pas, faut être 
> un peu gonflé ;-).
> J'ai pris un point au hasard 
> https://www.openstreetmap.org/node/5429129253#map=17/47.67817/-0.94895
> Je vois que c'est à proximité immédiate de La Verzée.
> Sur le site indiqué c'est un point de La Verzée.
> Donc deux possibilités :
> - l'info est meilleure
> - l'info est moins bonne (décalée ou pire).
> 
> Dans le second cas la solution est simple ;-)
> Dans le premier il faut importer le bout de ruisseau et remplacer le 
> bout équivalent existant (pour ne pas perdre les attributs).
> Ce n'est pas une opération triviale : il faut bien connaître JOSM et OSM.
> Donc à ne pas faire seule, cherche quelqu'un du côté de chez toi ou tu 
> sauvegarde les modifications localement et tu demandes à quelqu'un sur 
> la liste par exemple de vérifier.

Bonjour,

J'avais pris mes précautions et vérifier chaque nœud.
Quelques points étaient en doublon parce que mieux placés. J'ai effacé
dans JOSM tous ceux qui me semblaient apporter moins d'infos que ceux
qui existaient déjà. Sauf peut-être un ou deux ponts qui m'auraient
peut-être échappés sur La Verzée, je n'ai pas touché à cette rivière (ni
aux autres waterway=river) qui me semblaient bien tracée dans
l'ensemble. J'aurais ensuite revérifié et affiné directement sur la
carte en ligne. J'ai laissé des tracés d'origine qui me semblaient plus
précis sur la carte en ligne.

Le but était d'abord et avant tout de placer les ruisseaux manquants.
Mais aucun way n'a été tranféré. J'ai encore le fichier d'origine qui
a été construit à l'aide d'un fichier SHP issu de la source qui est
fiable et relativement précise car vérifié progressivement sur le
terrain par les techniciens fonctionnaires. Il y des aspects légaux en
terme d'agriculture par exemple, derrière leur démarche.

J'ai bien noté ce que recommande Marc Marc à propos de l'attribut
sources. Mais dans ce cas où doit-on mettre le source dans JOSM ?
Je ne savais pas que JOSM était limité à 1 nœuds (où trouve t-on
cette valeur ?). J'avais pourtant choisi une zone qui me semblait très
limitée par rapport à l'objectif. Il faudra que je le fasse à l'avenir
par tranche plus fine.

> J'annule et on repart de 0 ? :-)
C'est-à-dire ?

Puis-je refaire un essai avec un seul ruisseau ?

Cordialement.
-- 
Alain Rpnpif

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

Re: [Talk-es] Calles muy estrechas

[Jesús Lopez]

Buenos días.

Estoy de acuerdo con Rafael. Pienso que la calle es residencial sin depender de 
su ancho. Si es demasiado estrecha y no permite el paso de algún tipo de 
vehículo siempre se puede añadir algún tipo de restricción al vial [1].

Saludos

[1] https://wiki.openstreetmap.org/wiki/Key:access


> El 23 feb 2018, a las 01:29, Rafael Avila Coya  
> escribió:
> 
> Hola, Daniel:
> 
> Naturalmente, mapeamos lo que es correcto, nunca para el renderizador ;)
> 
> En mi opinión, una calle puede ser residencial aún cuando no puedan pasar 
> coches, pues es posible que el tránsito de motos siga siendo posible y 
> permitido.
> 
> Un saludo,
> 
> Rafael.
> 
> [1] https://www.openstreetmap.org/#map=18/40.41762/-3.68265
> 
> On 23/02/18 00:17, dcapillae wrote:
>> Estos días estoy revisando el callejero de los pueblos de Málaga para
>> preparar la importación de edificios y direcciones del Catastro [1], y he
>> podido comprobar que muchas calles estrechas de los pueblos de Málaga, de
>> uso fundamentalmente peatonal y por donde no pasa un coche, están mapeadas
>> como «highway=residential».

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

Re: [Talk-it] mia prima modifica in OSM - help!

[Martina]

ok, mappato come nodo con railway=station. Tolto il precedente tag
all'edificio e anche il name e aggiunto public_transport= station

Guardando gli altri tag dell'edificio mi sono però resa conto che ci sono
anche i tag wikipedia e wikidata. Li lascio sull'edificio o li sposto sul
nodo?

Martina

Il giorno 18 febbraio 2018 19:40, Federico Cortese 
ha scritto:

> 2018-02-18 13:14 GMT+01:00 Martin Koppenhoefer :
> >
> > le stazioni railway=station si possono mappare sia come nodo che come
> way,
> > ma quando sono mappati come way descrivono tutta la stazione (compreso
> > binari ecc.), quindi su un building=train_station non va quasi mai un
> > railway=station
> >
>
> +1
>
> Ciao,
> Federico
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Josm off line, come salvare la visione aerea

[Francesco Pelullo]

Il 23 feb 2018 09:23, "riccardopastoc...@alice.it" <
riccardopastoc...@alice.it> ha scritto:

Buon giorno,
spesso mi trovo a mappare in modalità off line, cioè dalla stanzetta
autisti del 118 dove non abbiamo internet.



Ciao

Ti suggerisco di evitare di farlo.
È molto facile entrare in conflitto con altri edit o addirittura con te
stesso, quando vai a fare l'upload.

Se non sei esperto e ti capita un conflitto, rischi di perdere tutto il
lavoro che hai fatto.

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

Re: [Talk-it] Josm off line, come salvare la visione aerea

[Cascafico Giovanni]

Ciao,
presumo tu sia su windows.

Le immagini di Bing e Mapbox mi sembra siano gestite come TMS (tile map
service), cioè sono composte di tanti tasselli  il cui nome è __.png

Cerca dov'è la cartella che li contiene andando in impostazioni JOSM,
accendi la casella "modalità avanzata", clicca la chiave inglese in basso e
cerca "imagery.tms".
Troverai qualcosa di simile a:
C:\Users\nomeutente\appData\Local\Temp\JMapViewerTiles_nomeutente

Quando sei online, la cartella si riempie di taselli mano a mano che di
sposti ed ingrandisci. Prova a rimepire un po' questa cache, ricordandoti
di zoommare nelle zone di cui hai bisogno di dettaglio.

Quando hai terminato, disabilita la rete, riavvia JOSM e prova a navigare
nella stessa zona. A me le immagini restano visibili.

Probabilmente quando hai cercato di rivederle, ti sei mosso a livelli di
zoom che non avevi scaricato. Per facilitare la navigazione, sempre in
impostazioni avanzate, cerca il parametro "imagery.tms.default_autozoom"...
dovrebbe essere "true" cambialo in "false".




Il giorno 23 febbraio 2018 09:30, Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> Ciao Riccardo,
>
> gli sfondi aerei o satellitari tipo Bing sono solitamente servizi (come il
> WMS) che come tali sono utilizzabili solamente quando si è connessi.
> Tramite JOSM arriva una richiesta al server di Bing che risponde fornendo
> un'immagine (tassello) dell'area richiesta. Sono immagini che risiedono
> solamente temporaneamente nel pc e le data policy spesso richiedono
> espressamente che ciò avvenga.
>
> Immagino che ci sia qualche modalità per salvare le tiles (tasselli)
> offline, non so quanto regolare sia... magari qualcun altro ha più
> esperienza.
>
> Ale
>
> On 23/02/2018 09:22, riccardopastoc...@alice.it wrote:
>
> Buon giorno,
> spesso mi trovo a mappare in modalità off line, cioè dalla stanzetta
> autisti del 118 dove non abbiamo internet.
>
> Ma non riesco a capire come salvarmi la cartina con la visione aerea (es
> Bing) da sovrascrivere a Josm.
>
> Descrivo il mio procedimento, in modo che possiate capire l'errore.
>
> 1) Da casa in modalità on line, mi apro Josm seleziono l'area di lavoro e
> salvo: file_salva come_   "data+ora" .osm
> e fin qui tutto bene perchè quando vado in modalità off line, mi riapro il
> file e tutto funziona;
> tranne il fatto che mi salva solo il file josm, quindi le linee che
> traccio io,ma non il livello di Bing (modalità aerea).
>
> 2) allora ho provato a salvare il livello Bing con estensione WMS  (Web
> Map Service), e succede che al al primo riavvio del Pc riesco ad aprire
> anche la mappa Aerea,
> ma se spengo e riaccendo il Pc, non mi apre più il file di Bing, o meglio
> me lo apre ma mi fa schermo nero  con scritte "nessun tassello in questo
> livello di ingrandimento".
>
> 3) provando a "spippolare" tra sottocartelle e file adesso non riesco a
> far riaprire il livello di Bing neanche al primo riavvio
>
>
>
> *Chiedo gentilmente di utilizzare terminologia consona ad un principiante,
> grazie*
>
> Riccardo Pastocchi
>
>
>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
>
> --
> --
>
> Alessandro Sarretta
>
> skype/twitter: alesarrett
> Web: ilsarrett.wordpress.com
>
> Research information:
>
>- Google scholar profile
>
>- ORCID 
>- Research Gate
>
>- Impactstory 
>
>
> ___
> 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-be] Where to suggest/discuss the renderer?

[Tim Couwelier]

The problem is - whenever you try and get changes for the renderer - the
argument is they don't feel they should change the renderer to try and
influence the tagging. They care about rendering 'the tags that actively
get used'.

Be very carefull how you pitch the argument, or it'll instantly get a big
red 'denied' stamp on it merely based on that argument.

2018-02-23 8:22 GMT+01:00 marc marc :

> Le 23. 02. 18 à 07:44, Karel Adams a écrit :
> > Whence my repeated question: where or with whom can this be discussed?
>
> the tagging mailing for the schema
> https://lists.openstreetmap.org/listinfo/tagging
>
> github to use a current schema
> https://github.com/gravitystorm/openstreetmap-carto/
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fwd: [OSM-talk] Highway=trunk : harmonization between countries ?

[Tim Couwelier]

There's always an inherit 'gap' between 'what does government intend the
road for' and 'how does the road actually look'.
Terms such as 'primary' and 'secondary' roads have meaning in planning
context.
In Flanders we have the 'Ruimtelijk Structuurplan Vlaanderen' which
classifies which roads are 'hoofdwegen' and which are primary (divided in
classes I and II)
Each Province has a 'Provinciaal Ruimtelijk Structuurplan', which
clasfficies which roads are secondary. (divided in classes I, II and III)
Each city/town is also supposed to have a 'Gemeentelijk Mobiliteitsplan'
which states which classification 'local' roads get, divided in classes I,
II and II)

There's potential for a very close match:

E and A roads are 'hoofdwegen'  => Tag as 'motorway'
The primary roads (regardless of their 'collecting' or 'connecting'
subtyping)  => tag as primary
The secondary roads (also regardless of their subtyping) => tag as secondary
The local roads types I and II => tag as tertiary
The local roads types III (aka 'the rest') => multitude of tagging options.

With the current tagging system and how it's applied in Belgium, we go
somewhere in between, but it's fairly 'clean' as it stands.
We don't look at what the government says, we go by 'how it looks' and link
that to the road numbering system for the' gewestwegen'.
Key point to decide on is if we SHOULD bother with 'intent' rather then
'reality', as 'mapping what's on the ground' is a basic principle.


Relating back to the post Joost distributed:
I do agree with most of the points, although 'trunk' is the odd part out.
'trunk' we don't use as a hierarchical classification, but to point out
it's a strech with a certain setup, i.e. forbidden for cyclists and such.


To end I'll repeat the example I've given in the riot channel about the
subtle difference between 'intended' and 'assumed':
The R32 ringroad around Roeselare.
Given it's a 'ringroad' it's classified in OSM as 'primary' all around.
But from the 'planning context' viewpoint, only the last stretches towards
the E403 are 'primary', and the majority is only 'secondary'. While the
road goes around Roeselare, it's function is to get people from and towards
the E403 'in either direction'. Due to the E403 being present, it's never
the intention to use the R32 to go around the entire end, as the E403 helps
cover that function.

PS:
If you have a look at said area, you'll also notice a part of 'trunk'.
Rendering wise, it 'feels' like the classification is different, and in
reality it looks different, but its function isn't really different at all.
Along with the aforementioned nuance primary/secondary, it's a second
example on how you could interpret on the same road.


2018-02-22 21:45 GMT+01:00 joost schouppe :

> Hi,
>
> Not wanting to change current consensus in Belgium, but I wonder how close
> this would be to current mapping practice in Belgium, and if it would be a
> way of thinking that could help in some current edge cases.
>
> -- Forwarded message --
> From: Fernando Trebien 
> Date: 2018-02-15 19:14 GMT+01:00
> Subject: Re: [OSM-talk] Highway=trunk : harmonization between countries ?
> To: t...@openstreetmap.org
>
>
> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
>
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
>
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above
>
> For example, the best route between two villages would be at least
> tertiary. So would be the best route between a village and a town or a
> city. Parts of this route might have a higher class in case they are
> part of a route between more important places.
>
> It surely raises the problem of determining optimal routes. Maybe a
> sensible criterion would be average travel time without traffic
> congestion. A number of vehicles may be selected for this average -
> could be motorcycle+car+bus+truck, or simply car+truck.
>
> Early results in my area [4, in Portuguese] seem promising and have
> produced more consensus than any previous proposals. To me, this
> method seems to:
> - resist alternations in classification along the same road
> - work across borders (where classification discontinuities are
> expected because each country is 

Re: [Talk-es] Calles muy estrechas

[dcapillae]

Gracias, Javier.

Estoy de acuerdo en usar «highway=footway» para calles estrechas. Respecto a
«highway=service», tiendo a no usarlo cuando se trata de calles propiamente
dichas, con nombre reconocido y reconocible.

La etiqueta «highway=service» la reservo exclusivamente para mapear vías de
servicio: acceso a gasolineras, caminos de entrada a viviendas, acceso a
zonas de aparcamientos, y cosas por el estilo. No las uso en el caso de
calles con nombre. Aunque también es cierto que la etiqueta
«highway=service» admite mapear vías de servicio con nombre, así que quizás
sea posible mapear calles con «highway=service».



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-es] Calles muy estrechas

[Javier Sánchez Portero]

Respuesta breve: yes

Aunque aquí nos metemos en la cuestión de si asumir valores por defecto o
no que lleva mucho debate detrás. Las vías footway de la zona que mandé
(Barrio Nuevo, Tenerife), para mi son footway puro y duro. Físicamente se
pueden meter motos y bicicletas (y seguro que se hace), pero no creo que
legalmente esté autorizado. Para mi son como aceras.

El 23 de febrero de 2018, 8:47, alan_gr  escribió:

> Si usamos footway, sería necesario añadir bicycle=yes en muchos casos? Y
> tal
> vez motorcycle=yes, moped=yes o horse=yes según el caso?
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

Ahoj,
dobrá zpráva. Data v POI-Importeru byla aktualizována.

A povedlo se mi i umravnit generování json souborů, takže mohu použít git
pro detekci změněných souborů a jejich automatickou aktualizaci na serveru.
Zároveň mám hotový i první nástřel update skriptu. Ještě musím dodělat
nějaké logování a kontrolu chyb a můžu to pustit automaticky.

https://github.com/mkyral/POI-Importer_CP_pbox_tiles/commit/b1b5da5b4ef42bec
9e24afd177755adb906a432f

Snad o víkendu.

Marián


-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 22. 2. 2018 12:45:04
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )
"
Dovolím si odpovědět za Mariána:
hlavní problém je, že je třeba to párování aktualizovat, což se dva dny
nestalo, pokud chápu dobře.

V této chvíli se páruje se primárně přes ref, přes vzdálenost jen pokud už
ke spárování přes ref nedošlo. 




Hlavní ale je: dokud nedojde k aktualizaci u Mariána, rozdíl tam zůstane.
Nestačí opravit data OSM.




Majka



2018-02-22 12:28 GMT+01:00 Petr Vozdecký :
"
...tedy primarni vlastnost pro parovani (situace, kdy POIimporter vi, co 
chce v tabulce porovnavat) je vzdalenost? Hraje tam nejakou roli ref=*?

vop


"



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

Re: [Talk-es] Calles muy estrechas

[alan_gr]

Si usamos footway, sería necesario añadir bicycle=yes en muchos casos? Y tal
vez motorcycle=yes, moped=yes o horse=yes según el caso?



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-it] [Imports] Fwd: Re: Sabbioneta buildings import

[Andrea Musuruane]

Hi!

On Thu, Feb 22, 2018 at 9:57 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 22. Feb 2018, at 14:41, Andrea Musuruane  wrote:
> >
> > * You should also add building=yes to bell towers.
>
>
> I would suggest building=bell_tower
>
>
Actually in the wiki there is written to add building=yes in case of free
standing bell tower:
https://wiki.openstreetmap.org/wiki/Tag:tower:type%3Dbell_tower

BR,

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