Re: [OSM-talk] Sidewalk symmetry

[Marc Gemis]

I wonder why those arguments always pop up when we talk about separate
sidewalks and not when we talk about separate cycleways.
AFAIK it is common practice to map cycleways as separate ways in OSM
as soon as there is a kerb.

Don't we encounter the same problems in data processing for cycleways ?

m.

On Tue, Apr 24, 2018 at 8:56 PM, Tobias Knerr  wrote:
> On 24.04.2018 02:17, Clifford Snow wrote:
>> But if you want
>> someone to use the data, then map it as separate ways.
>
> That's not the case, and it's a bit frustrating to read this just after
> I wrote a mail explaining this point. To reiterate:
>
> * With separate ways, we don't know which road section a sidewalk
> belongs to.
> * This knowledge is necessary for many applications.
>
> For such a fundamental property, "research scientists believe they can
> use the spatial proximity" is not good enough imo. It has to be
> practical to obtain this relationship from OSM data.
>
> ___
> 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] Sidewalk symmetry

[Lauri Kytömaa]

Ed Loach wrote:

>where there is a verge so narrow you can step across it without stepping on 
>the grass.

Unless you're with a walker, a pram or a stroller, or in a wheelchair.

> or put arbitrary joining ways at intervals.
Only useful where there's a real connection anyway, i.e. a route
starts from or crosses the highway; be it a driveway (garages count),
crossing, footway (or similar) leading away from road, or the intended
connection between sidewalk segments across the intersecting road. I
don't think any of these are any more arbitrary than the fact that in
intersection the two crossing ways both describe the area inside the
intersection, i.e. if the ways were expanded into areas with their
width, the areas overlap where the ways cross, but that's just the way
the model is.


-- 
alv

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

Re: [OSM-talk] New wave of Pokémon Go mappers – check the parks

[Roland Olbricht]

Hi,

Michael, thank you for pointing to the problem. The query finds parks 
that existed already on April 23rd midnight. I think the relevant parks 
are rather those parks that have changed since that date. Thus, I 
suggest the query


[timeout:120]
[bbox:{{bbox}}];
(
 way[leisure=park];
 rel[leisure=park];
 way[leisure=garden];
 rel[leisure=garden];
 way[recreation_ground];
 rel[recreation_ground];
 way[leisure=playground];
 rel[leisure=playground];
 way[leisure=pitch];
 rel[leisure=pitch];
 way[landuse=grass];
 rel[landuse=grass];
);
(way._(newer:"2018-04-23T00:00:00Z")->.w;rel._(newer:"2018-04-23T00:00:00Z"););
out geom meta;

Best regards,
Roland

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

Re: [OSM-talk] [Diversity-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Marc Gemis]

FYI The unisex tag is also used as a shorthand for female=yes,  male=yes on
shop=hairdresser [1] . Giving it another meaning on toilets might cause
extra confusion.


regards

m

[1] https://wiki.openstreetmap.org/wiki/Tag:shop=hairdresser

Op di 24 apr. 2018 18:27 schreef Rory McCann :

> Hi all,
>
> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
>
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
>
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
>
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
>
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
>
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
>
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
>
> Rory
>
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
>
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> [4]
> https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
>
> ___
> Diversity-talk mailing list
> Code of Conduct:
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Diversity-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Marc Gemis]

FYI The unisex tag is also used as a shorthand for female=yes,  male=yes on
shop=hairdresser [1] . Giving it another meaning on toilets might cause
extra confusion.


regards

m

[1] https://wiki.openstreetmap.org/wiki/Tag:shop=hairdresser

Op di 24 apr. 2018 18:27 schreef Rory McCann :

> Hi all,
>
> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
>
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
>
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
>
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
>
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
>
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
>
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
>
> Rory
>
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
>
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> [4]
> https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
>
> ___
> Diversity-talk mailing list
> Code of Conduct:
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[Talk-dk] Fællesskabsressourcer i osm-community-index til bl.a. iD-editor

[Mikkel Kirkgaard Nielsen]

Halløj.

Jeg har tilføjet Danmark og nedenstående danske fællesskabsressourcer
til det nye osmlab-projekt "osm-community-index"[1]. Det er et projekt
der forsøger at samle geo-kodede informationer om kommunikationskanaler,
kontaktinfo, begivenheder mm. fra OSM-fællesskaberne, så de kan
præsenteres af systemerne for relevante brugere og bidragsydere.

Talk-dk: https://lists.openstreetmap.org/listinfo/talk-dk
#osm-dk: irc://irc.oftc.net/osm-dk
OSM-forum: https://forum.openstreetmap.org/viewforum.php?id=48

Er der andre relevante ressourcer at tilføje, så gør endelig det i
projektet, eller meld tilbage her så skal de nok komme på.


Indekset bruges bl.a. af iD-editoren i v2.8.0[2] til en forbedret dialog
efter upload, der henviser til de ressourcer der findes i det netop
redigerede område.

Flere detaljer og eksempel kan ses i iD-projektet[3], ellers prøv at
rediger+gem med iD på openstreetmap.org[4] og se det selv (de
danskspecifikke ressourcer er ikke slået igennem pt., så de globale vises).

Hygge,
-- 
Mikkel

[1] https://github.com/osmlab/osm-community-index/pull/115
[2] https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#280
[3] https://github.com/openstreetmap/iD/issues/4815
[4] https://www.openstreetmap.org/edit?editor=id




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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[James]

not only that, bit generally in North America, men's washrooms are usually
dirtier than woamns washrooms

On Tue, Apr 24, 2018, 2:46 PM Kathleen Lu,  wrote:

> I think the most likely application may be the other way around, where
> transgender individuals concerned about harassment may purposefully seek
> out restrooms that are designated unisex in order to reduce the chances of
> encountering someone who might challenge whether they are using the
> "correct" restroom.
> -Kathleen
>
> On Tue, Apr 24, 2018 at 11:12 AM Frederik Ramm 
> wrote:
>
>> Hi,
>>
>> On 04/24/2018 08:02 PM, Tobias Zwick wrote:
>> > Why do you think it necessary to map at all if any particular toilet is
>> > segregated or not beyond whether I can go there as a man/woman? What is
>> > the application?
>>
>> I know people of both standard genders who would prefer using a toilet
>> that is for their gender's exclusive use over a toilet that is for all
>> genders.
>>
>> Their respective reasons for doing so are based on unflattering
>> stereotypes so I won't repeat them here, but there definitely *are*
>> people who do not only want to know "can I use that toilet" but also
>> "who else can use that toilet".
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Michael Kugelmann]

Am 24.04.2018 um 22:13 schrieb Florian Lohoff

Ich packe ein lit=yes auch auf andere als
highway Objekte. Z.b. wenn ein Parkplatz beleuchtet ist bekommt das
amenity=parking auch ein lit=yes

Vorgehensweise macht für mich Sinn => würde ich befürworten. +1


Grüße,
Michael.



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

[OSM-talk] New wave of Pokémon Go mappers – check the parks

[Michael Reichert]

Hi,

Pokémon Go seems to have updated its OpenStreetMap data [1] leading to
an higher than usual number of new mapppers adding parks – some or many
of them are fictional. It is a good idea to check
http://resultmaps.neis-one.org/newestosm for your country (click on the
flags to show only edits from your country) and use Overpass API queries
looking for ways tagged with like leisure=park, natural=grassland or
landuse=grass which have been modified recently.


This might be a suitable Overpass query.

[date:"2018-04-23T00:00:00Z"]
[timeout:120]
[bbox:{{bbox}}];
(
 way[leisure=park];
 rel[leisure=park];
 way[leisure=garden];
 rel[leisure=garden];
 way[recreation_ground];
 rel[recreation_ground];
 way[leisure=playground];
 rel[leisure=playground];
 way[leisure=pitch];
 rel[leisure=pitch];
 way[landuse=grass];
 rel[landuse=grass];
);
out geom meta;

Please be friendly even if all edits of a user are junk. Add a changeset
comment to all reverted changeset to inform other mappers that they can
continue reviewing other changesets and comment one of the changesets of
the newbie telling him that edits have to match the reality on the
ground. You might include a link to
https://blog.openstreetmap.org/2018/04/01/tips-pokemon-go-2/#

Best regards

Michael


[1]
https://www.reddit.com/r/TheSilphRoad/comments/8ehf8u/new_nests_osm_data_has_officially_changed_nests/


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Talk-de] OSMF-Vorstand tagt in Karlsruhe

[Frederik Ramm]

Hallo,

am Wochenende ist eine Klausurtagung ("Face-to-Face-Meeting") des
OSMF-Vorstands in Karlsruhe.

Samstag abend (28.4. 19:30) ist die Community beim gemeinsamen
Abendessen im Restaurant "Zum Kleinen Ketterer"
(https://www.openstreetmap.org/node/4413801140) willkommen. Bitte sagt
mir bescheid, wenn ihr kommen wollt, damit ich sicherstellen kann, dass
genug Plätze reserviert sind.

Bye
Frederik

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

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

Re: [OSM-ja] 高速道路の定義について

[tomoya muramoto]

>(1)「高速道路ナンバリング付きの道路を highway=motorway とする。」という選択枝に、下記の追加オプションもお願いできるでしょうか？
>   - 追加 (1) ただし自動車専用道路に限る
>上記の意図は、例えば、西九州自動車道（E35）の二丈浜玉道路（当面活用区間）は自動車専用ではないがナンバリング区間になっているようですが（はっきりそうかは不明）、highway=motorway
とするかという問いです。

こちらへのリアクションが抜けていました。

こんな事例があるのですね。追加しておきます。

なお私の案としては、二丈浜玉道路は"highway=motorway + access=yes(またはfoot=yes + bicycle=yes +
'軽車両'=yes)"とタグ付けして、motorwayのアクセス制限を上書きすればよいのではないかと思います。
('軽車両'=yesは、別途議論が進んでいるaccessタグ規定の中で決まるであろうタグのことです)

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

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Harald Schwarz]

Hallo zusammen,

also ob wir in Düsseldorf auch noch originale Gaslaternen aus den 80ern, also 
der Zeit zwischen 1880 und 1890 haben, kann
ich nicht sagen, aber bei uns beleuchten noch ca. 14000 die Straßen mit ihrem 
schönen Licht. 
Die ältesten sind mindestens 100 Jahre alt, die jüngsten werden ungefähr 50 
Jahre alt sein. Neuere gibt es nur bei Ersatz durch Unfall oder Sturmschaden.

Und die 14000 Gaslaternen sind natürlich auch in OSM erfasst. Beschreibung dazu 
ist zu finden unter: 
https://wiki.openstreetmap.org/wiki/D%C3%BCsseldorf/Projekte/Gaslaternen


Zur Beleuchtung mittels LED:

Ich habe angefangen, das in Düsseldorf mittels lit_by_led=yes zu erfassen. Das 
Ergebnis sieht man hier: https://overpass-turbo.eu/s/yd6


Liebe Grüße aus Ratingen
   Harald Schwarz
   black_bike



> Gesendet: Samstag, 21. April 2018 um 13:10 Uhr
> Von: Morray 
> An: "Openstreetmap allgemeines in Deutsch" , 
> "Frederik Ramm" 
> Betreff: Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland
>
> Servus,
> 
> sehe das so wie Du. Nachtwanderung wäre nötig. 
> 
> Folglich tagge ich bei lit eigentlich nur den Fall "no" bzw. nur in der 
> Nacht. 
> 
> Ohnehin viel interessanter und auch immer nachprüfbar sind die Laternen 
> ("Highway=street_lamp"). Also trage ich diese ein. Meist haben sie auch noch 
> Nummern ("ref"), ein Aufstelldatum ("start_date"), eine Höhe ("height"), 
> einen Durchmesser ("width"), eine Modellbezeichnung ("lamp_model") und 
> unzählige weitere Angaben aufgedruckt. 
> 
> BG
> morray
> 
> PS. Die älteste Laterne die ich bis jetzt gefunden habe ist aus den 80ern. 
> Wer findet ältere.
> 
> Am April 21, 2018 8:02:15 AM UTC schrieb Frederik Ramm :
> >Hallo,
> >
> >ich habe mal gezählt, wie oft "lit" an Ways mit highway=* in
> >Deutschland
> >vorkommt:
> >
> > 487245 yes
> > 180915 no
> >   2365 limited
> >336 24/7
> >308 sunset-sunrise
> >261 opposite
> >246 automatic
> >101 disused
> > 35 interval
> > 29 1
> > 23 temporarily
> > 14 Dämmerung - 23 Uhr; 5 Uhr - Sonnenaufgang
> >  9 twilight
> >  9 dusk_dawn
> >  8 no;yes
> >  8 Mo-Su 18:00-22:00
> >  8 Mo-Su 05:00-22:00
> >  7 operating_times
> >  7 Mo-Su 18:00-24:00
> >  7 lit=yes
> >  6 light_switch
> >  5 unknown
> >  5 sparsely
> >  5 operating times
> >
> >und noch ein paar gequetschte. (Bei "lit=yes" dachte ich erst an einen
> >Programmfehler, aber https://www.openstreetmap.org/way/565098324 gibt's
> >tatsächlich).
> >
> >Wie geht ihr vor, wenn ihr lit=* mappt? Wenn ich am Tage durch eine
> >Straße fahre und Laternen sehe, reicht das schon für ein "lit=yes"
> >(sicherlich sind die Laternen nicht zum Spaß da), oder muss ich prüfen,
> >ob die tatsächlich auch angehen? Das Wiki schreibt, nach der Erklärung
> >der Laternenring-Ausnahme (s.u.): "Alle anderen Laternen müssen nach
> >StVO die ganze Nacht über brennen und können auch entsprechend getaggt
> >werden, ohne eine Nachtwanderung zu machen." - vom Gefühl her
> >widerstrebt es mir etwas, aus dem bloßen Vorhandensein einer Laterne
> >auf
> >eine nächtliche Beleuchtung zu schließen, denn bei OSM mappen wir ja in
> >der Regel, was "ist" und nicht was "nach StVO sein muss".
> >
> >Berücksichtigt ihr (oder findet ihr, dass man das tun sollte) bei der
> >Vergabe von lit=* den "Laternenring"
> >(https://de.wikipedia.org/wiki/Laternenring), der angibt, dass die
> >Laterne nicht die ganze Nacht leuchtet?
> >
> >Das Wiki empfiehlt, "lit=yes" auch bei unbekannter Leuchtdauer zu
> >verwenden, schreibt zugleich (was eigentlich dazu ein Widerspruch ist),
> >dass man lit=limited verwenden könne, wenn ein Laternenring dran ist.
> >
> >Ich habe mal gelesen, dass Gemeinden zum Stromsparen nur jede zweite
> >Laterne die ganze Nacht brennen lassen. Aber ich kann doch in so einem
> >Fall die Straße nicht in lauter 50m lange Stücke unterteilen, die Hälte
> >mit lit=yes und die andre Hälfte mit "lit=". In gewisser
> >Weise
> >ist ja schon die ganze Straße beleuchtet, auch wenn nur die Hälfte der
> >Lampen an ist. Bloß halt nich so gut...
> >
> >Und was ist, wenn auf einer Straßenseite Laternen sind und auf der
> >anderen nicht?
> >
> >
> >So viele Ways haben lit=yes, nach Straßentyp:
> >
> > 178893 residential
> >  60099 footway
> >  58973 secondary
> >  39344 tertiary
> >  32147 service
> >  28245 primary
> >  26495 path
> >  15792 living_street
> >  13583 unclassified
> >   8792 steps
> >   7508 cycleway
> >   6910 pedestrian
> >   1747 track
> >   1614 trunk
> >   1348 primary_link
> >   1226 secondary_link
> >   1086 trunk_link
> >   1002 motorway_link
> >977 motorway
> >
> >und lit=no
> >
> >  39990 motorway
> >  26389 track
> >  22590 footway
> >  15808 path
> >  13454 secondary
> >  11987 primary
> >  10315 motorway_link
> >   8198 service
> >   6587 tertiary
> >   5350 unclassified
> >   5065 residential
> >   4035 trunk
> >   3831 cycleway
> 

Re: [Talk-cz] Data ze ZÚ

[jzvc]

Dne 24.4.2018 v 21:13 Miroslav Suchý napsal(a):

Dne 24.4.2018 v 10:53 Pavel Machek napsal(a):

znamena
to ze je to uredni dilo, mohou se libovolne kopirovat / pouzivat?

Obávám se, že tohle není úřední dílo. Viz definice v § 3 Autorského zákona:

§ 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu
Ochrana podle práva autorského se nevztahuje na
a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné
povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho
listin, jakož i úřední návrh úředního díla a jiná přípravná úřední
dokumentace, včetně úředního překladu takového díla, sněmovní a senátní
publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol
jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem
na vyloučení z ochrany,
b) výtvory tradiční lidové kultury, není-li pravé jméno autora obecně
známo a nejde-li o dílo anonymní nebo o dílo pseudonymní (§ 7); užít
takové dílo lze jen způsobem nesnižujícím jeho hodnotu.

Mirek


Klidne se to do toho vejde, bud jako verejna listina nebo jako verejne 
pristupny rejstrik (co jinyho je trebas katastr). Tohle musis brat jako 
priklady, podstatne je predevsim "a jiná taková díla, u nichž je veřejný 
zájem na vyloučení z ochrany", coz by samozrejme pripadne musel zase 
nejspis resit soud (kez by kazdy jeden, kdo se uz s temi byrokraty 
soudi, zaroven vysoudil, ze to ten konkretni nasledne zaplati ze sve 
kapsy, ne z te nasi).


Osobne bych typnul, ze vetsina soudu bude rozhodovat prave na zaklade 
toho, kdo vytvoreni daneho vytvoru zaplatil - pokud stat/samosprava => 
je to uredni dilo (za predpokladu, ze jeho vytvoreni zakon predpoklada) 
nebo je to zlodejina (nebot urad smi cinit jen to, co mu zakon cinit 
uklada).






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



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

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Martin Koppenhoefer]

sent from a phone

> On 24. Apr 2018, at 22:13, Florian Lohoff  wrote:
> 
> . Z.b. wenn ein Parkplatz beleuchtet ist bekommt das
> amenity=parking auch ein lit=yes
> 
> Macht das noch wer?


ja, gelegentlich 

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

Re: [Talk-cz] Data ze ZÚ

[jzvc]

Cus, trochu ti vstoupim do tvych kruhu ...

ty licence na ta data se (podle me) tykaji ovsem databazi, nikoli 
napriklad fotomapy, protoze to databaze neni.


Ad cena, nemuzou chtit nic. Pokud se tedy budeme bavit o vecech jako 
trebas prave ta fotomapa, ktera verejna je, jen tu v souvislosti s OSM 
je vedena polemika na tema licence. Jinak se da rict, ze urad muze 
pozadovat uhradu nakladu na poskytnuti tech dat tobe. Pokud cela operace 
predstavuje nejaky automatizovany export a ulozeni na nejake medium, tak 
se bavime o radove stokorunach max (tzn vybrat ty penize bude stat o rad 
vic, nez kolik se vybere).


BTW: Kdyz se podivas do meta ty fotomapy, tak tam najdes toto 

Omezení zdroje
Legislativní omezení služby
Podmínky pro přístup a užití: Žádné podmínky neplatí.
Podmínky pro přístup a užití: Výdejní jednotka není stanovena.
Podmínky pro přístup a užití: Bez poplatků.
Omezení veřejného přístupu: jiné omezení
Jiná omezení: Opětovnému využití dat zpřístupněných službou pro obchodní 
účely je zamezeno začleněním ochranných znaků (copyright ČÚZK).

Jiná omezení: Podmínky užití viz Obchodní podmínky ZÚ
Bezpečnostní omezení služby
Klasifikace: neklasifikované



Dne 24.4.2018 v 11:44 Honza Cibulka napsal(a):

Zdar,
je to trochu složitější: prostorová data ve smyslu zákona o právu na informace 
o životním prostředí může stát zpřístupňovat na základě nevýhradní licenční 
smlouvy [1], která může stanovit podmínky jejich využití, jako i cenu za 
zpřístupnění těch informací. Takže to není nic jako úřední dílo. Soud řekl, že 
zde nejsou autorská práva třetích stran, např. soukromých firem, která by 
bránila poskytnutí těch informací veřejnosti.

Jde tedy o dvě otázky:

- jak vysokou částku si může úřad (ZÚ) za data účtovat?
- jak restriktivní může být licence (když si to koupim, můžu z toho 
trasovat do OSM)?

No a na to není žádnej úplně jasnej návod. V případě ceny zákon stanoví [2], že za data 
"může být požadována úhrada ve výši, která nepřesáhne minimální výši nezbytnou k 
zajištění potřebné kvality a zpřístupňování prostorových dat". Což je přesně kolik? 
Patří do toho i náklady na pořízení těch dat? Náklady na geoportál? Výkladová literatura 
ani judikatura na tuhle otázku (aspoň kam sahaj moje znalosti) spíš neodpovídá. Zkrátka 
proto, že doposaváde všichni platili, co si ZÚ účtoval, a nikdo do toho nešťoural. Můj 
pohled na věc jsem naznačil v blogu [3], ale závazně to bude vykládat nejdřív ZÚ, pak 
ČÚZK a pak možná zas soud.

K licenci pak zákon stanoví [4], že "podmínky poskytnutí informace v licenční nebo 
podlicenční smlouvě musí umožňovat další užití informace žadatelem v souladu se 
žádostí", takže teoreticky v žádosti by člověk měl uvést, že z dat hodlá trasovat do 
OSM a licence by s tím měla počítat. Imho pak z textu zákona neplyne, že by ZÚ mohl s 
ohledem na účel stanovený v licenci navýšit cenu, ale zase, závazně to vyloží někdo jinej.

V obou případech se to týká poskytnutí na žádost, věcí vyvěšených na 
prohlížecích službách se to netýká. Zda tedy úřad může stanovit licencí 
mantinely pro využití prohlížecích služeb a co všechno může uživatelům zakázat 
(aby to nebyla svévole), taky nevíme. ZÚ tu licenci soudně nevymáhá (ptal jsem 
se na právnim, prej to nikdy neudělali, takže co si kdo ukradne, to má), akorát 
občas zablokujou přístupy z nějaký IP.

Osobně si myslim, že všechny tyle otázky se měly už dávno zodpovědět v rámci 
GeoInfoStrategie [5] a navazujících projektů, jenže tam se řešej důležitejší 
věci [6]. Takže zbejvá průzkum bojem (litigací).

Honza Cibulka

[1] https://www.zakonyprolidi.cz/cs/1998-123/zneni-20150901#p11c-1
[2] https://www.zakonyprolidi.cz/cs/1998-123/zneni-20150901#p11c-3
[3] http://gismentors.cz/blog/soud-nastavil-mantinely-cenam-dat-ze-zu/
[4] https://www.zakonyprolidi.cz/cs/1999-106/zneni-20170801#p14a-3
[5] http://www.mvcr.cz/clanek/geoinfostrategie.aspx
[6] https://giphy.com/gifs/gal-gadot-6J6QQ8Rc2IaKQ


-Original Message-
From: Pavel Machek 
Sent: úterý 24. dubna 2018 10:54
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Data ze ZÚ

Ahoj!


jelikož se rozhodnutím soudu [1] zas dal do pohybu spor o data ZÚ, měl
bych volně související teoretickou otázku: jaké datové sady
Zeměměřického úřadu [2] by pro tuzemské OSM byly nejpřínosnější?
Proč? A funguje něco takového v zahraničí?
  http://gismentors.cz/blog/soud-nastavil-mantinely-cenam-dat-ze-zu/

Dobre zpravy :-).

Pokud soud rozhodl ze autorska prava na data ZU nalezi statu, znamena to ze je 
to uredni dilo, mohou se libovolne kopirovat / pouzivat? To by byla dobra 
zprava, protoze bez ohledu na to co si ZU uctuje by bylo mozne data koupit 
jednou a pak je proste vystavit na ftp... (pripadne ukecat nekoho kdo uz data 
zakoupil aby poskytl kopii na ftp / DVD...)

A ortofoto je tady: http://geoportal.cuzk.cz/geoprohlizec/?wmcid=2012
Pokud na nem neni ochrana podle autorskeho zakona, tak nam nic nebrani ho 
stahnout a zacit 

[Talk-de] Gehweg kurzes Stück nicht straßenbegleitend, oder path ohne Widmung?

[Martin Koppenhoefer]

Vor ein paar Monaten war mir ein Gehweg aufgefallen, der als highway=path ohne 
weitere access tags getaggt war.
Infolge meiner Korrektur (bicycle no) hat sich eine längere Unterhaltung 
ergeben, und nachdem mein Gesprächspartner mich dazu aufgefordert hat, bitte 
ich Euch jetzt auch um eure Einschätzung. Es geht um die beiden Wege in diesem 
Changeset und um die in der Diskussion angesprochenen Punkte:

https://www.openstreetmap.org/changeset/54888423#map=15/48.7575/9.1704


Gruß,
Martin 


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

Re: [Talk-us] STOP - All vehicles must register

[Peter Dobratz]

The first thing that comes to mind is a barrier=toll_booth:

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth

Perhaps also with a fee=no to indicate that you don't have to pay any money.

Peter

On Fri, Apr 20, 2018 at 11:10 AM Kevin Kenny 
wrote:

> The case of non-hard-surface roads brought this to mind.  There are a few
> roads across the Adirondack Park that are open to the public (in summer)
> and have endpoints that look like
>
> http://i65.tinypic.com/2enq9ew.jpg
>
> In this case, I already recognize - tag the two cabins (they are a ranger
> station, not often staffed), the gate, the outhouse, the well, perhaps the
> signage. But what to do about the kiosk/register?
>
> The requirement is that vehicles (or bicycles, pedestrians, horses, etc.)
> must stop, and the party leader fills out an entry in the book that's kept
> in one of the boxes on the kiosk. (There happen to be two books at that
> location; one for vehicles that are merely traversing the road and another
> for hikers, skiers, and riders who are venturing off-road into the
> backcountry) The understood procedure is that it's all right to pass as
> long as the gate is unlocked, and the expectation is that drivers will
> leave the gate as they found it - close it if they opened it.
>
> Is there an OSM tag for "this is where you stop and execute formalities"
> that I've missed? I know that calling it out as an access restriction on
> the road has been controversial, and I don't tag that because any scheme
> gets someone up in arms. For this reason, tagging that registration is a
> requirement to drive on the road is Out Of Scope. I'm simply trying to tag
> the on-the-ground "this is where you stop and register."
>
> By the way, I'd tag the road in the picture as at least
> highway=unclassified and possibly even tertiary. In the seasons when it's
> open (usually late April to early November, depending on snow conditions)
> it's the main route between the villages of Indian Lake and Inlet, and when
> it's closed the trip is many miles longer. The registration requirement is
> largely to make sure that drivers have all the warnings in front of their
> faces - they're going to be spending the next hour driving on an unpaved
> road across some very forbidding country, with no services available and no
> mobile phone coverage nor radio call boxes. (It's also there because Search
> and Rescue isn't going to give quite the same treatment if someone goes
> missing without having signed in.)
>
> There are simpler but similar setups on some footways - where the hiker
> must not only register, but take the carbon copy along as proof of
> registration. (The plan is that sometimes the number of forms will be
> limited as a primitive means of 'first come, first served' capacity
> control. I don't think it's ever actually got that far.)
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Florian Lohoff]

On Sat, Apr 21, 2018 at 10:02:15AM +0200, Frederik Ramm wrote:
> Hallo,
> 
> ich habe mal gezählt, wie oft "lit" an Ways mit highway=* in Deutschland
> vorkommt:
> 
>  487245 yes
>  180915 no
>2365 limited

Ich hab da noch ne frage. Ich packe ein lit=yes auch auf andere als
highway Objekte. Z.b. wenn ein Parkplatz beleuchtet ist bekommt das
amenity=parking auch ein lit=yes

Macht das noch wer?

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk] Name:* tags in the local language

[Yuri Astrakhan]

Adding a language=xx to each feature seems excessive, and will be forgotten
most of the time, unless there is some extensive tool support for it.
Adding it to admin regions seems like a better approach.  Some utility
could then calculate a clean translation map, using admin_level number as
the deciding factor in case of multiple values.

On a side note, a validation tool can than be used to check if "name" has
the same value as "name:xx", where xx is taken from that calculated map.
(I'm sure in many cases it won't match because some places use "lang:local
- lang:en" style of naming for the name tag.

On Tue, Apr 24, 2018 at 10:48 PM, Jo  wrote:

> I thought we were already indicating which language name is in, with the
> name:language=:iso tag?
>
> Hmm, apparently not:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Language_information_for_name
>
> Polyglot
>
> 2018-04-24 21:29 GMT+02:00 Richard Fairhurst :
>
>> Paul Norman wrote:
>> > If there's agreement that there is a problem here, I could look
>> > at preparing a mechanical edit or MapRoulette challenge to add
>> > name:* tags, e.g. adding name:en to objects in the US with
>> > other name:* tags, and adding name:zh in China. As an
>> > estimate, this would be 115k changes in China, touching 28%
>> > of roads there.
>>
>> This is pretty fragile too, though. Two minutes after the mechanical
>> edit, a
>> newbie will come along and change the name= tag on a random American road
>> from MLK Boulevard to Martin Luther King Boulevard, without knowing they
>> now
>> have to change the name:en= tag as well. Bang, inconsistent data. Fast
>> forward two years and a bunch of history-losing way splits, and it's no
>> longer clear which is the accurate street name and which is the original,
>> mistaken TIGER-imported one.
>>
>> In theory you could bake support for this into editing software (at the
>> expense of complicating the interface), but even if JOSM, iD, Vespucci and
>> P2 all add support, the name= tag is probably the most likely to be
>> changed
>> by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
>> they'll all add the same logic.
>>
>> Mateusz Konieczny wrote:
>> > This language=en tag would be placed on a administrative
>> > relation, right?
>>
>> If I read Frederik's proposal right, the language=en tag would be placed
>> on
>> the object with the name tag, though putting it on admin relations is an
>> interesting idea.
>>
>> Richard
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.
>> html
>>
>> ___
>> 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] Name:* tags in the local language

[Jo]

I thought we were already indicating which language name is in, with the
name:language=:iso tag?

Hmm, apparently not:

https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name

Polyglot

2018-04-24 21:29 GMT+02:00 Richard Fairhurst :

> Paul Norman wrote:
> > If there's agreement that there is a problem here, I could look
> > at preparing a mechanical edit or MapRoulette challenge to add
> > name:* tags, e.g. adding name:en to objects in the US with
> > other name:* tags, and adding name:zh in China. As an
> > estimate, this would be 115k changes in China, touching 28%
> > of roads there.
>
> This is pretty fragile too, though. Two minutes after the mechanical edit,
> a
> newbie will come along and change the name= tag on a random American road
> from MLK Boulevard to Martin Luther King Boulevard, without knowing they
> now
> have to change the name:en= tag as well. Bang, inconsistent data. Fast
> forward two years and a bunch of history-losing way splits, and it's no
> longer clear which is the accurate street name and which is the original,
> mistaken TIGER-imported one.
>
> In theory you could bake support for this into editing software (at the
> expense of complicating the interface), but even if JOSM, iD, Vespucci and
> P2 all add support, the name= tag is probably the most likely to be changed
> by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
> they'll all add the same logic.
>
> Mateusz Konieczny wrote:
> > This language=en tag would be placed on a administrative
> > relation, right?
>
> If I read Frederik's proposal right, the language=en tag would be placed on
> the object with the name tag, though putting it on admin relations is an
> interesting idea.
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html
>
> ___
> 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] Name:* tags in the local language

[Christoph Hormann]

On Tuesday 24 April 2018, Frederik Ramm wrote:
>
> Someone once suggested to have a special tag that indicates which
> name tag should be used by default. I.e. we'd have tons of "name:xx"
> tags plus one tag called e.g. "language=en", that would then mean:
> The default name to use is the name:en name.

I think that someone was me. :-)

Details on:

http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/

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

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

Re: [OSM-talk] Name:* tags in the local language

[Richard Fairhurst]

Paul Norman wrote:
> If there's agreement that there is a problem here, I could look 
> at preparing a mechanical edit or MapRoulette challenge to add 
> name:* tags, e.g. adding name:en to objects in the US with 
> other name:* tags, and adding name:zh in China. As an 
> estimate, this would be 115k changes in China, touching 28% 
> of roads there.

This is pretty fragile too, though. Two minutes after the mechanical edit, a
newbie will come along and change the name= tag on a random American road
from MLK Boulevard to Martin Luther King Boulevard, without knowing they now
have to change the name:en= tag as well. Bang, inconsistent data. Fast
forward two years and a bunch of history-losing way splits, and it's no
longer clear which is the accurate street name and which is the original,
mistaken TIGER-imported one.

In theory you could bake support for this into editing software (at the
expense of complicating the interface), but even if JOSM, iD, Vespucci and
P2 all add support, the name= tag is probably the most likely to be changed
by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
they'll all add the same logic.

Mateusz Konieczny wrote:
> This language=en tag would be placed on a administrative 
> relation, right? 

If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag, though putting it on admin relations is an
interesting idea.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [Talk-it] osm2pgsql su windows

[Alessandro Palmas]

Il 24/04/2018 20:02, Martin Koppenhoefer ha scritto:
Ci sono tileserver vettoriali, dovresti trovare tanti informazioni 
nel wiki di osm.




A SOTM2018 ci sarà almeno un workshop sull'argomento

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

Re: [Talk-cz] Data ze ZÚ

[Miroslav Suchý]

Dne 24.4.2018 v 10:53 Pavel Machek napsal(a):
> znamena
> to ze je to uredni dilo, mohou se libovolne kopirovat / pouzivat?

Obávám se, že tohle není úřední dílo. Viz definice v § 3 Autorského zákona:

§ 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu
Ochrana podle práva autorského se nevztahuje na
a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné
povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho
listin, jakož i úřední návrh úředního díla a jiná přípravná úřední
dokumentace, včetně úředního překladu takového díla, sněmovní a senátní
publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol
jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem
na vyloučení z ochrany,
b) výtvory tradiční lidové kultury, není-li pravé jméno autora obecně
známo a nejde-li o dílo anonymní nebo o dílo pseudonymní (§ 7); užít
takové dílo lze jen způsobem nesnižujícím jeho hodnotu.

Mirek



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

Re: [OSM-talk] Name:* tags in the local language

[Mateusz Konieczny]

24. Apr 2018 20:03 by md...@xs4all.nl :


> I think you're opening another can of worms here. How would this work out for 
> me (in Dutch) where I don't want to see places in latin script translated? I 
> do not want to see Londen or Berlijn or Brunswijk, I also don't want to see 
> English translations like Cologne or Munich, but I do want to see readable 
> (i.e. non-Cyrillic, Kanji, Hangul, etc) names.
>




Simple fallback would not work here but something like that may work

if name tag has only latin characters use name tag

otherwise fallback through following name tags:

name:nl, name:de, name:en...

With such scheme missing name:nl would not cause problems here (except
cases where dutch name has characters beyond latin script, I have no
idea whatever it may happen).

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

[OSM-co] Validando Tareas!!

[Alejandra Diaz]

Hola a Todos



La Cruz Roja Americana y el proyecto Missing Maps en Colombia, como parte
de la construcción de la cartografía preventiva del país y con miras a
tener una comunidad más activa ha venido realizando diferentes mapatones en
Bogotá, Chía, Manizales, Bucaramanga, Ibagué y Tunja, es para nosotros de
gran importancia comunicarle a toda la comunidad de estas actividades y de
los logros alcanzados, y en esta oportunidad queremos hacer un llamado a
participar en el proceso de validación de la Tarea de Bucaramanga la cual
se encuentra mapeada en un 33% y la validación tiene un 2%, sabemos que con
su colaboración estaremos más cerca de contar con una cartografía
confiable, de fácil acceso, para todos y de todos!!



Bucaramanga: *https://tasks.hotosm.org/project/3975
*



Muchas gracias por la contribución,




*Alejandra Diaz Suescún **| Gis Analyst | International Services | American
Red Cross*

*Av Cra 68 No. 66 B 31 | Bogotá, Colombia*

*Skype: g...@amcross.org *

*Celular: 3134338220*
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk] Sidewalk symmetry

[Tobias Knerr]

On 24.04.2018 02:17, Clifford Snow wrote:
> But if you want
> someone to use the data, then map it as separate ways. 

That's not the case, and it's a bit frustrating to read this just after
I wrote a mail explaining this point. To reiterate:

* With separate ways, we don't know which road section a sidewalk
belongs to.
* This knowledge is necessary for many applications.

For such a fundamental property, "research scientists believe they can
use the spatial proximity" is not good enough imo. It has to be
practical to obtain this relationship from OSM data.

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

Re: [OSM-talk] Name:* tags in the local language

[Sarah Hoffmann]

On Tue, Apr 24, 2018 at 08:16:08PM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 04/24/2018 07:23 PM, Paul Norman wrote:
> > If there's agreement that there is a problem here, I could look at
> > preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> > e.g. adding name:en to objects in the US with other name:* tags, and
> > adding name:zh in China. As an estimate, this would be 115k changes in
> > China, touching 28% of roads there.
> 
> Even if there should be agreement that there is a problem here, there
> are other potential solutions.
> 
> Someone once suggested to have a special tag that indicates which name
> tag should be used by default. I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
> 
> I think this would be more elegant than the duplication that you are
> suggesting.

That still doesn't scale. You will have a hard time to convince mappers
to repeatedly add something to objects for which there is an obvious
default. This really should be solved at least partially in software.

I'd like to point to https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
again. This list is a good place to start when you want to guess the
language a name tag is in and solves the case for monolingual coutries.
Multilingual countries tend to be more sensitive to the language issue
so that coverage with name:* tags tends to be better.

Also don't mix up the issue of languages and scripts. name:zh is
a point in case where knowing the language doesn't help you if you
want to present the users the map in their favourite script. name:zh
will normally contain Pidgin but may also have traditional Chinese
from time to time.

I strongly recommend to have a look into Sven's work on the German
mapnik style, which has been trying to address a lot of issues with
localized maps: https://github.com/giggls/mapnik-german-l10n

Sarah

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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Kathleen Lu]

I think the most likely application may be the other way around, where
transgender individuals concerned about harassment may purposefully seek
out restrooms that are designated unisex in order to reduce the chances of
encountering someone who might challenge whether they are using the
"correct" restroom.
-Kathleen

On Tue, Apr 24, 2018 at 11:12 AM Frederik Ramm  wrote:

> Hi,
>
> On 04/24/2018 08:02 PM, Tobias Zwick wrote:
> > Why do you think it necessary to map at all if any particular toilet is
> > segregated or not beyond whether I can go there as a man/woman? What is
> > the application?
>
> I know people of both standard genders who would prefer using a toilet
> that is for their gender's exclusive use over a toilet that is for all
> genders.
>
> Their respective reasons for doing so are based on unflattering
> stereotypes so I won't repeat them here, but there definitely *are*
> people who do not only want to know "can I use that toilet" but also
> "who else can use that toilet".
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Name:* tags in the local language

[Mateusz Konieczny]

On Tue, 24 Apr 2018 20:16:08 +0200
Frederik Ramm  wrote:

> I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
> 
> I think this would be more elegant than the duplication that you are
> suggesting.

This language=en tag would be placed on a administrative relation,
right?

Note that it would work only in places with single language, and even
in very homogeneous countries, with single culture there are some
correctly tagged objects with name tag in a different languages.

So it would be anyway necessary to supply name:en to names that are in
English to confirm that this names are really in English.

This method would also not work at all in places with more complex
language situation (multiple communities, each using local language).

On top of that it is a bit complicated to use as a data consumer.

Overall I am not convinced that it is a good replacement.

PS My comments in future will be from a matkoni...@tutanota.com email,
that is still me - not some impostor.

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

Re: [OSM-talk] Name:* tags in the local language

[Tobias Knerr]

On 24.04.2018 19:23, Paul Norman wrote:
> It is sometimes recommended that when you add a name in another language
> you also indicate the name in the local language by adding a suitable
> name:* tag at the same time. For example, if adding "name:fr=Londres" to
> London, you would also add "name:en=London" if it weren't present.
> 
> This practice is not widely followed.

I have to say I'm not a fan of this practice, at least for
straightforward cases.

Yes, there are parts of the world where explicit language information is
necessary. But in many others, there is an obvious default, and it feels
wrong to require mappers to manually repeat this on millions of
individual elements. Don't add extra tags to German names in Germany,
for example – tag the exceptions from the rule instead.

As a less important secondary point, I also consider the specific
tagging (duplicating the name with a different key) counter-intuitive
and would prefer a "language of the name" key, with the language given
as the value. The purpose of that tag would be much more
self-documenting than with the recommendation described above.

That being said, displaying labels in the user's language is an exciting
use case, and I hope we can find a solution that allows your project to
succeed. Could you elaborate a bit more on the technical limitations
regarding regional processing?

> Fixing this in software doesn't work
> well because it requires regional processing of what are increasingly
> small regions as you get to less used languages.

You mention increasingly small regions as the obstacle. Would that still
allow for the pragmatic compromise of setting country-level defaults,
and using explicit tagging only for smaller-scale language regions?

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

[OSM-talk] Name:* tags in the local language

[Frederik Ramm]

Hi,

On 04/24/2018 07:23 PM, Paul Norman wrote:
> If there's agreement that there is a problem here, I could look at
> preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> e.g. adding name:en to objects in the US with other name:* tags, and
> adding name:zh in China. As an estimate, this would be 115k changes in
> China, touching 28% of roads there.

Even if there should be agreement that there is a problem here, there
are other potential solutions.

Someone once suggested to have a special tag that indicates which name
tag should be used by default. I.e. we'd have tons of "name:xx" tags
plus one tag called e.g. "language=en", that would then mean: The
default name to use is the name:en name.

I think this would be more elegant than the duplication that you are
suggesting.

Bye
Frederik

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

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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Frederik Ramm]

Hi,

On 04/24/2018 08:02 PM, Tobias Zwick wrote:
> Why do you think it necessary to map at all if any particular toilet is
> segregated or not beyond whether I can go there as a man/woman? What is
> the application?

I know people of both standard genders who would prefer using a toilet
that is for their gender's exclusive use over a toilet that is for all
genders.

Their respective reasons for doing so are based on unflattering
stereotypes so I won't repeat them here, but there definitely *are*
people who do not only want to know "can I use that toilet" but also
"who else can use that toilet".

Bye
Frederik

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

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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Tobias Zwick]

Why do you think it necessary to map at all if any particular toilet is
segregated or not beyond whether I can go there as a man/woman? What is
the application?

On 24/04/2018 18:27, Rory McCann wrote:
> Hi all,

> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
> 
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
> 
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
> 
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
> 
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
> 
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
> 
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
> 
> Rory
> 
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
> 
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> 
> [4] https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
> 
> ___
> 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] Name:* tags in the local language

[Maarten Deen]

On 2018-04-24 19:40, Mateusz Konieczny wrote:

I fully agree that it is a problem. I encountered nasty issues after
implementing name rendering fallback with following language order
(order is simplified for this example):

name:pl, name:en, name:de, name

Intention was to render English name in China/Korea rather than
unreadable (for typical person from Poland) local name.

The result was rendering German names in Poland, because name:pl was
missing and name:de was present.


I think you're opening another can of worms here. How would this work 
out for me (in Dutch) where I don't want to see places in latin script 
translated? I do not want to see Londen or Berlijn or Brunswijk, I also 
don't want to see English translations like Cologne or Munich, but I do 
want to see readable (i.e. non-Cyrillic, Kanji, Hangul, etc) names.


Maarten

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

Re: [Talk-it] osm2pgsql su windows

[Martin Koppenhoefer]

sent from a phone

> On 24. Apr 2018, at 12:26, Roberto Brazzelli  wrote:
> 
> Per postres invece .io ho un server debian (soluzione cloud) che uso 
> per pubblicare mappe con lizmap..potrei isntallare postgis e anche 
> osm2pgsql? corretto?


forse non ti conviene la soluzione cloud se vuoi renderizzare tutto il mondo, 
perché avrai esigenze elevate di RAM e IO

con mapnik puoi fare mappe raster, mapbox ha mappe vettoriali. Ci sono 
tileserver vettoriali, dovresti trovare tanti informazioni nel wiki di osm.

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

[Talk-ca] Réserves, gestion de la faune

[Pierre Béland]

Le contributeur webfil a fait un excellent travail au Québec de cartographier 
les différentes réserves naturelles et territoires de la gestion de la faune. 
Si vous regardez la carte du Québec, vous verrez que ceci comprend de larges 
portions du territoire dans les zones forestières.

Je ne sais ailleurs au Canada, mais au Québec en plus des parcs nationaux et 
réserves strictes de protection de la faune, écologie ou autre, il y a deux 
catégories supplémentaires des territoires publics de gestion de la faune 
(activités de chasse et pêche). Ces territoires sont souvent aussi grands que 
les parcs nationaux.- Zec - gestion par une association
- Pourvoiries - concession de l'exploitation d'un territoire à une entreprise 
privée

Suite à la discussion sur le changeset 
https://www.openstreetmap.org/changeset/53933324#map=8/49.465/-62.898, je 
poursuis ici.

Webfil a classifié 
parc national : boundary=national_parc, leisure=nature_reserve
ZEC: boundary=protected_area, protected_class=7, leisure=national_reserve
Réserve faunique: boundary=protected_area, protected_class=4, 
leisure=national_reserve
Réserve écologique: boundary=protected_area, protected_class=1, 
leisure=national_reserve
Pourvoiries : landuse=commercial

La classification pour les pourvoiries m'apparait inadéquate. On pourrait soit 
classifier de façon similaires aux ZEC, soit indiquer uniquement 
leisure=nature_reserve.

En comparaison, je vois en Colombie-Britannique, un territoire classifié 
leisure=nature_reserve
Relation : Dewdrop-Rosseau Wildlife Management Area (2238697)
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] Name:* tags in the local language

[Mateusz Konieczny]

I fully agree that it is a problem. I encountered nasty issues after
implementing name rendering fallback with following language order
(order is simplified for this example):

name:pl, name:en, name:de, name

Intention was to render English name in China/Korea rather than
unreadable (for typical person from Poland) local name.

The result was rendering German names in Poland, because name:pl was
missing and name:de was present.

Somebody else also encountered this issue and places in Poland are
now partially fixed.

On Tue, 24 Apr 2018 10:23:19 -0700
Paul Norman  wrote:

> preparing a mechanical edit or MapRoulette challenge

I would consider also making a quest in StreetComplete (it is on my
TODO list since a long time).

In my experience StreetComplete is working much better that
MapRoulette, though I am not sure whatever this task fits well "local
survey" model.

In case of mechanical edit - can you consider sharing script
(hopefully one working without complex environment)? I would happily run
such mechanical edit in Poland (including obtaining permission from
local community, checking whatever edits are correct and potential
cleanup of wrong edits).

Making mechanical edit is also on my TODO list since a long time, but
it never went further than vague plan and half-written explanation why
it is useful.

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

Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Mateusz Konieczny]

On Tue, 24 Apr 2018 18:27:02 +0200
Rory McCann  wrote:

> Thoughts? Feedback? Anything I'm missing?

Note that defining tag with proposal on wiki will not change existing
data or immediately change how people understand tag.

I was not investigating the situation in this case but have you
considered inventing new tag, not tainted by confusion that you
described (I have no idea is it a good idea in this particular
situation).

> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people

I think that it is preferably to skip such parts, I am not convinced
that adding political discussion is an useful addition.

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

[OSM-talk] Name:* tags in the local language

[Paul Norman]

As part of my Wikimedia Foundation work, I'm working on labeling in
multiple languages using OSM data. We've run into an issue, and it's not
clear how to best solve it.

It is sometimes recommended that when you add a name in another language
you also indicate the name in the local language by adding a suitable
name:* tag at the same time. For example, if adding "name:fr=Londres" to
London, you would also add "name:en=London" if it weren't present.

This practice is not widely followed. For example, 3% of the roads with
names in multiple languages in the western US have a name:en tag.[1]
Cities are better, but still only 30% of cities and towns with names in
multiple languages have a name:en tag. For the same criteria in China
and with Chinese, it's 30% of roads and 75% of cities.[2]

This is a problem for displaying labels. Proper display of labels is
more than just showing the name in the language the user requested and
falling back to the name=* tag. It requires falling back through
multiple languages. For example, if someone requests a map in
Luxembourgish, you would show German labels where places and objects
have no Luxembourgish names. There are similar situations for French
Creoles and many regional and minority languages.

We'd like to be able to do more. Specifically, we'd like to always show
labels in the user's script if possible. For example if a French user is
viewing a map of India, they're more likely to be able to read an
English name than one in a Dravidian language, Hindi, or Bengali. The
common lack of a name:* tag for the primary language while having other
name:* tags makes this impossible.

There aren't any great solutions. Fixing this in software doesn't work
well because it requires regional processing of what are increasingly
small regions as you get to less used languages. Language detection from
the tag value is fragile and introducing magic logic. This really needs
addressing on the OSM data side.

If there's agreement that there is a problem here, I could look at
preparing a mechanical edit or MapRoulette challenge to add name:* tags,
e.g. adding name:en to objects in the US with other name:* tags, and
adding name:zh in China. As an estimate, this would be 115k changes in
China, touching 28% of roads there.

[1]: https://phabricator.wikimedia.org/T192662#4151714
[2]: https://phabricator.wikimedia.org/T192662#4147291


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

Re: [Diversity-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Hannah Cohoon]

I was just adding some unisex bathrooms and was following the
toilets:for:unisex=yes method. However, I agree that unisex=yes is more
intuitive to mean "unisex bathroom" not "male=yes female=yes" and it's more
pithy than what I've been doing. I also just joined the project and had
initially assumed unisex=yes was correct until I saw the information here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
.

All that is to say, I support assuming unisex=yes means gender neutral and
think revising the wiki would be appropriate.


On Tue, Apr 24, 2018 at 11:27 AM Rory McCann  wrote:

> Hi all,
>
> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
>
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
>
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
>
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
>
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
>
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
>
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
>
> Rory
>
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
>
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> [4]
> https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
>
> ___
> Diversity-talk mailing list
> Code of Conduct:
> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org

-- 

Doctoral Student

School of Information at UT Austin

UTA 5.544
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Rory McCann]

Hi all,

Let's have a wee talk about how should one map gender neutral (and
gender segregated) toilets. There is a unisex=yes for toilets which
looks like it might be the number one tag to use. The bog standard
meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
segregated into separate male & female facilities.

Many smaller public toilets are single occupancy and hence unisex, many
larger public toilets (e.g. in shopping centers) are segregated. Social
conservatives are mostly losing the battle on same-sex marriage, so
their new target is trans people, and they're proposing "bathroom laws"
to limit trans people's access to public life. Some organizations are
making their toilets "gender neutral" in response. So there are probably
a lot of gender neutral public toilets, and it's very useful for some
people to know where they are.

But I don't think that's how "unisex=yes" been used in OSM. The wiki
page says "unisex=yes" is a shorthand for "male=yes female=yes". The
JOSM validator used to suggest that replacement, until I filed a bug[2].
iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
it won't let you add both male=yes female=yes.

If I see "amenity=toilets unisex=yes", I would think this is a gender
neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
think gender segregated. Big difference.

I propose that we start viewing "unisex=yes" on toilets as meaning
"gender neutral toilet", which is different from "male=yes female=yes",
which is "gender segregated".

Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
by many projects? What do they interpret it as? It's good not to force
things.

A year ago Micah Cochran's suggestion[3] would be along these lines, but
some changed to toilets:for:unisex=yes (etc.)

Rory

P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
which for the quarter is gendered toilets. Plenty of toilets have no
male/female (and/or unisex) tag, and we should add those tags.

[1] https://en.wikipedia.org/wiki/Unisex_public_toilet
[2] https://josm.openstreetmap.de/ticket/15536
[3] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements

[4] https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2

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

Re: [Talk-pt] Levantamento funcional Cascais

[David Vale]

No próximo ano haverá mais, pelo que se houver áreas com maior interesse de
actualização de dados, posso considerar... Tem é que ser uma área que tenha
os edificios já digitalizados, de forma a que os alunos consigam adicionar
as funções.

Abraços a todos
David


David Vale
Assistant Professor
Lisbon School of Architecture - University of Lisbon
Rua Sá Nogueira, 1349-063 Lisboa- Portugal
T: (351) 213 615 067 F: (351) 213 625 138


2018-04-24 14:53 GMT+01:00 Rui Oliveira :

> Excelente iniciativa.
>
> Um aparte. Não sabia que tinha aqui colegas de universidade como o David.
>
> Bom saber :)
>
>
> A ter, 24/04/2018, 13:53, Marcos Oliveira 
> escreveu:
>
>> Obrigado pelo avisoe desde já obrigado por introduzires os teus alunos
>> neste projecto. :)
>>
>> A terça, 24/04/2018, 12:21, David Vale  escreveu:
>>
>>> Bom dia
>>>
>>> Queria apenas avisar que, no âmbito do trabalho de grupo da unidade
>>> curricular "Geografia Urbana" do mestrado integrado em Arquitectura, os
>>> alunos estão a realizar um levantamento funcional do r/c dos edificios do
>>> concelho de Cascais. Assim, devem ter reparado que temos vários novos
>>> utilizadores registados recentemente, e queria avisar que nas próximas
>>> semanas iremos ter um registo eventualmente anormal de novas edições no
>>> OSM, que corresponderão à introdução desta informação no OSM.
>>>
>>> Quero com isto sensibilizar os alunos para a importância de contribuirem
>>> para o OSM mas também que posteriormente todos possam utilizar a
>>> informação. A recolha foi feita por zona (cada aluno ficou responsável por
>>> um deteminado local - quadrícula - do concelho de Cascai), mas depois
>>> iremos trabalhar com o conjunto de dados total.
>>>
>>> Obrigado e cumprimentos,
>>> David Vale
>>> Assistant Professor
>>> Lisbon School of Architecture - University of Lisbon
>>> Rua Sá Nogueira, 1349-063 Lisboa- Portugal
>>> T: (351) 213 615 067 F: (351) 213 625 138
>>>
>>> ___
>>> Talk-pt mailing list
>>> Talk-pt@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-pt
>>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Martin Koppenhoefer]

sent from a phone

> On 24. Apr 2018, at 16:06, dan980  wrote:
> 
> Al limite si può fare:
> 
> brand=Independent
> brand:IT=Pompe Bianche


due brand sbagliati come compromesso?
;-)

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

Re: [OSM-ja] 高速道路の定義について(まとめページ)

[yuu hayashi]

hayashiです

Ras and Road へのレスです

「路線バス」と「小型特殊自動車」 について調べてくださってありがとうございます。
さっそく継承図に反映させていただきます。

それと、質問をいただきましたので 回答させていただきます。

> 「highway=motorway」とマッピングするだけで何かが変わってしまうのですか。

現在、JapanTaggingでは 「highway=motorway」
には「自動車専用道路標識」を定義しています。（標識がない場合については記述があいまいですが）
これはOpenStreetMapというデータベースの日本エリアにおける「仕様」となっています。
マッパーはこの仕様に従ってマッピングを行ってきましたし、ユーザ（データベースの利用者）はこの仕様を見て、仕様に合わせた製品なりサービスを開発します。
この仕様が突然変更になると、今回の場合では、いままで「自動車専用道路」であったものがある日突然「自動車専用道路」でなくなります。
たいていのカーナビにはルート検索機能がついています。ルート検索の際に「有料道路を避ける」とか「自動車専用道路を避ける」などの機能が実装されていて、小型バイクや自転車ユーザはこの機能をよく利用します。
仕様変更で 「自動車専用道路」 が 「自動車専用道路」 でなくなると、自転車ユーザが 「自動車専用道路」 へ誘導されてしまいます。
最終的には「標識」を見て交通ルールにのっとった判断が必要ですが、ルート計画が適切に行なえなくなるのではカーナビの意味がなくなります。
海外の判例ですがカーナビで誘導された結果、事故を起こしてカーナビのメーカーと地図サービス会社が損害賠償を支払うことになった。という事例もあります。
「有料道路」についての情報は tall
タグがあるので良いのですが、accessタグについては日本の車両種別に合わせた仕様が策定されていないため登録できていない状態にあります(自転車は登録できますが)。
現行では 「自動車専用道路」 を表す「highway=motorway」だけが「車両種別規制」を表す有効なタグになります。
そのため、カーナビ各社は 「自動車専用道路を避ける」 機能の実装に 「highway=motorway」を参照しているはずです。
高速道路や国道などの道路のレンダリングは各社それぞれの差別化が図られるところなので実装方法は各製品毎で違っていますが、
現行のカーナビでも「高速道路」はちゃんと表示できています。
（だから highway=motorway をわざわざ「高速道路」にする必要はないのです）

highway=motorway の定義を変えると、すでに市場に出回っている製品は 正しく「自動車専用道路」を表示できなくなります。
開発中のプロダクトは仕様変更後の「
自動車専用道路」に合わせて製品を改修する必要があります。企業のビジネスですのでOSMに対する追及もシビアになると思われます。私が担当のマネジャなら変更の理由を問いただします。変更理由を問いただすのは今後このような変更がどのぐらいの確率で発生するのかを予測するためです。
なっとくできる理由がなく変更されたと判断された場合は、今後も頻繁に仕様変更が発生することが予測されるので、今後はOSMの採用をしないことにします。（OSMが好きなわたしのような担当マネジャでもそう判断します。そうしないとクビになります）

OSMのようなデータベースの仕様はシステムやサービスの中核・基盤となる重要な部位なので、通常は仕様変更はほとんど行われません。（10年間変更なしもよくあります）
機能追加や変更を行う場合は互換性が確保されるように変更します。
致命的な不具合が発生してどうしても変更せざるを得ない場合でも「現行のアプリがそのまま動作できるように」します。
昨日の例に挙げた highway=bus_stop がその一例です。バス路線のルート検索をするために highway=bus_stop
という古い仕様をそのまま残して public_transport という新しいタグ体系を公共交通機関に定義しました。
古い仕様をそのまま残したことで古いアプリやレンダラーもそのまま使えます。public_transport  に対応した 新しいアプリは
バス路線のルート検索 機能を実装可能になるわけです。

OSMの理念には「自由に’使える’地図を」提供することにあります。マッパーが楽しむだけでなくユーザの視点での判断も必要です。
今回は長くなってしまったので 詳しい説明は省かせていただきますが、机上より現地を優先する理由も マッパーではなく 「ユーザ
のためのルール」とだけの説明にとどめさせていただきます。


2018年4月24日 23:14 Ras and Road :

> Ras and Roadです。
>
> まずは、xyzxyz2さんの4月19日01:30の投稿に対してのレスポンスです。
>
> > (1)「高速道路ナンバリング付きの道路を highway=motorway とする。」という選択枝に、
> 下記の追加オプションもお願いできるでしょうか？
> >- 追加 (1) ただし自動車専用道路に限る
> 例に挙げられた二丈浜玉道路に限らず、自動車専用道路でない当面活用区間は高速道路ナンバリングされないと思います。
> ・・・と思っていたのですが、あらためて高速道路ナンバリング資料を見たら、ナンバリング区間になってますね。
> http://www.mlit.go.jp/road/sign/numbering/map/index.html
> 鳥取道と一体運用の志戸坂峠坂根～駒帰間も同じ事態のようです。
> 俄には信じがたいですが、そんなウルトラＣが繰り出された場合であっても慌てることのないように、という意図と理解しました。
>
>
> 次に、hayashiさんの4月21日11:40の投稿に対する回答です。
>
> > （１）もし仮に、「通行通行止め」標識の下に「バス」とあった場合は、「路線バス」は通行可能ということでしょうか？
> 一般乗合旅客自動車運送事業者による路線定期運行の用に供する自動車であって、その車体が大型乗用自動車及び特定中型乗用自動車（＝バス）
> でなければ、通行可能です。
> わかりやすく言うと、路線バスの車体がハイエースクラスの車両なら通行できますね。
> 一般的には、誤解を防ぐために「バス」と「路線バスを除く」の補助標識が並架されると思います。
>
> > （３） 「小型特殊自動車」について、名称に「自動車」という文字があるので、「自動車」に分類しました。しかし、原典にはどこにも「自動車」
> であるとの記述を見つけることができませんでした。
> 「小型特殊自動車」は「自動車」として問題ないでしょうか？
> 小型特殊自動車の定義は道路交通法と道路運送車両法で異なりますが、道路運送車両法施行規則別表第一ならびに道路交通法施行規則第二
> 条でいずれも「自動車」と定義されています。
>
>
> 最後に、hayashiさんの一連の投稿で常に言われていることに対して質問（お願い）です。
> 「自動車専用道路をタギングすることはカーナビにとって重要」とのことですが、なぜそれが重要なのか、もう少し噛み砕いていただけると助かります。
> 「highway=motorway」とマッピングするだけで何かが変わってしまうのですか。
> そういう製品は、accessタグやtollタグも勘案してレンダリング或いはルーティングしていると想像していました。
> つまり、motorwayの定義を変えても、同時にaccess=*,toll=*を正しく設定すれば問題は発生しないと理解していたのですが、誤解ですか？
>
> ** Ras and Road **
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Paris Soirée de Contribution au Libre

[Christian Quest]

Présent (en principe) !

Sur Issy les données avaient déjà été intégrées, j'ai refait une passe 
il y a peu.


Si on reste sur cette thématique, il faudrait regarder les autres jeux 
de données dispo sur data.gouv.fr et évaluer leur "intégrabilité" ;)


https://www.data.gouv.fr/fr/search/?q=d%C3%A9fibrillateurs

Il y a plus d'une vingtaine de jeux de données disponibles...


Le 24/04/2018 à 10:49, Nicolas Bétheuil a écrit :

Hey,

kiki viendra ?
https://www.agendadulibre.org/events/16717

Je pense bosser sur les défibrillateurs de France & Navarre

A partir de https://www.data.gouv.fr/fr/search/?q=defibrillateur
Christian a déjà couvert Paris
https://twitter.com/cq94/status/988451160272011265
J'ai ajouté Issy ce matin là https://www.mapcontrib.xyz/t/7f46aa-Defibrillateur

Voir ce qu'on peut faire dessus
Des avis ?

___
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-in] Missing al5-boundaries in India

[Jinal Foflia]

Hello Walter,

Thanks so much for bringing this to our notice, the Indian Community is on
it!

Cheers,
Jinal Foflia

On Fri, Mar 2, 2018 at 7:02 PM, F11PES NARDANI 
wrote:

> I had a list of boundary node co ordinates but misplaced do you have one?
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Walter Nordmann 
> *Sent: *28 February 2018 20:02
> *To: *talk-in@openstreetmap.org
> *Subject: *[Talk-in] Missing al5-boundaries in India
>
>
> Hi,
>
> just found some gaps in the admin boundaries level 5 in India.
>
> https://wambachers-osm.website/images/osm/snaps_2018/india_al5.png
>
> where you see a blue background there is no al5 or may be it's damaged.
>
> could you please help and fix that gaps in your country?
>
> regards
>
> walter aka wambacher
>
> attached: list of all al5 found in OSM
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-ja] 高速道路の定義について(まとめページ)

[Ras and Road]

Ras and Roadです。

まずは、xyzxyz2さんの4月19日01:30の投稿に対してのレスポンスです。

> (1)「高速道路ナンバリング付きの道路を highway=motorway とする。」という選択枝に、下記の追加オプションもお願いできるでしょうか？
>- 追加 (1) ただし自動車専用道路に限る
例に挙げられた二丈浜玉道路に限らず、自動車専用道路でない当面活用区間は高速道路ナンバリングされないと思います。
・・・と思っていたのですが、あらためて高速道路ナンバリング資料を見たら、ナンバリング区間になってますね。
http://www.mlit.go.jp/road/sign/numbering/map/index.html
鳥取道と一体運用の志戸坂峠坂根～駒帰間も同じ事態のようです。
俄には信じがたいですが、そんなウルトラＣが繰り出された場合であっても慌てることのないように、という意図と理解しました。


次に、hayashiさんの4月21日11:40の投稿に対する回答です。

> （１）もし仮に、「通行通行止め」標識の下に「バス」とあった場合は、「路線バス」は通行可能ということでしょうか？
一般乗合旅客自動車運送事業者による路線定期運行の用に供する自動車であって、その車体が大型乗用自動車及び特定中型乗用自動車（＝バス）でなければ、通行可能です。
わかりやすく言うと、路線バスの車体がハイエースクラスの車両なら通行できますね。
一般的には、誤解を防ぐために「バス」と「路線バスを除く」の補助標識が並架されると思います。

> （３） 
> 「小型特殊自動車」について、名称に「自動車」という文字があるので、「自動車」に分類しました。しかし、原典にはどこにも「自動車」であるとの記述を見つけることができませんでした。
　 「小型特殊自動車」は「自動車」として問題ないでしょうか？
小型特殊自動車の定義は道路交通法と道路運送車両法で異なりますが、道路運送車両法施行規則別表第一ならびに道路交通法施行規則第二条でいずれも「自動車」と定義されています。


最後に、hayashiさんの一連の投稿で常に言われていることに対して質問（お願い）です。
「自動車専用道路をタギングすることはカーナビにとって重要」とのことですが、なぜそれが重要なのか、もう少し噛み砕いていただけると助かります。
「highway=motorway」とマッピングするだけで何かが変わってしまうのですか。
そういう製品は、accessタグやtollタグも勘案してレンダリング或いはルーティングしていると想像していました。
つまり、motorwayの定義を変えても、同時にaccess=*,toll=*を正しく設定すれば問題は発生しないと理解していたのですが、誤解ですか？

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[dan980]

io sono dell'idea di usare brand=independent , nell'ottica di mantenere una
coerenza internazionale. Al limite si può fare:

brand=Independent
brand:IT=Pompe Bianche



-
--
confronto navigatori basati su OSM:
https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml

--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-pt] Levantamento funcional Cascais

[Rui Oliveira]

Excelente iniciativa.

Um aparte. Não sabia que tinha aqui colegas de universidade como o David.

Bom saber :)


A ter, 24/04/2018, 13:53, Marcos Oliveira 
escreveu:

> Obrigado pelo avisoe desde já obrigado por introduzires os teus alunos
> neste projecto. :)
>
> A terça, 24/04/2018, 12:21, David Vale  escreveu:
>
>> Bom dia
>>
>> Queria apenas avisar que, no âmbito do trabalho de grupo da unidade
>> curricular "Geografia Urbana" do mestrado integrado em Arquitectura, os
>> alunos estão a realizar um levantamento funcional do r/c dos edificios do
>> concelho de Cascais. Assim, devem ter reparado que temos vários novos
>> utilizadores registados recentemente, e queria avisar que nas próximas
>> semanas iremos ter um registo eventualmente anormal de novas edições no
>> OSM, que corresponderão à introdução desta informação no OSM.
>>
>> Quero com isto sensibilizar os alunos para a importância de contribuirem
>> para o OSM mas também que posteriormente todos possam utilizar a
>> informação. A recolha foi feita por zona (cada aluno ficou responsável por
>> um deteminado local - quadrícula - do concelho de Cascai), mas depois
>> iremos trabalhar com o conjunto de dados total.
>>
>> Obrigado e cumprimentos,
>> David Vale
>> Assistant Professor
>> Lisbon School of Architecture - University of Lisbon
>> Rua Sá Nogueira, 1349-063 Lisboa- Portugal
>> T: (351) 213 615 067 F: (351) 213 625 138
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [talk-au] Am I doing intersections right?

[osm.talk-au]

Please don't break my placement tags. (I've restored them.) They were there on 
purpose, and they are not what causes OSRM to generate that "Turn left onto 
unnamed road" instruction. 

Also, please don't delete my transit relations, these things take a lot of work 
to properly setup without explicit editor support.

In case you are wondering what these tags are for, they are part of detailed 
lane tagging as you can see here:

https://www.dropbox.com/s/ednlniwp6bcl5wk/1521024394681.jpg?dl=0

The placement=transition tag is necessary to indicate that this particular 
segment is not actually where it is in the real world, but is necessary because 
of the discrepancy between mapping roads as lines and roads having a width an 
multiple lanes in the real world.

The transit relation is necessary to define which of the lanes from one way 
segment connect to which of the lanes in the next way segment. In this case it 
indicates that the leftmost turn lane flows straight into that slip road.


The other 3 slip roads at this intersection have the same tags, and they do not 
result in OSRM producing such a driving instruction. If there were any obvious 
tagging mistakes, I would have fixed them already.


Cheers,
Thorsten

> -Original Message-
> From: Michael 
> Sent: Tuesday, 24 April 2018 19:33
> To: 'OSM Australian Talk List' 
> Subject: Re: [talk-au] Am I doing intersections right?
> 
> Ok it seems the OSM website will not centre you on an area from a
> link but takes you back to the last area you looked at.
> 
> Now ... I have removed 2 tags from the slip lane sections.
> 
> 
> -Original Message-
> From: Michael 
> Sent: Tuesday, 24 April 2018 7:13 PM
> To: 'OSM Australian Talk List' 
> Subject: Re: [talk-au] Am I doing intersections right?
> 
> For some reason it wont show me the location of the pins when I go
> to that link.
> 
> I had looked at that area once before and noticed some odd stuff in
> josm but left it alone.
> 
> I've gone back in with josm and made some changes, if the routing
> starts working (note sure on caching times before we see it) then I
> would call it fixed.
> 
> 
> 
> -Original Message-
> From: osm.talk...@thorsten.engler.id.au  a...@thorsten.engler.id.au>
> Sent: Tuesday, 24 April 2018 6:46 PM
> To: 'OSM Australian Talk List' 
> Subject: Re: [talk-au] Am I doing intersections right?
> 
> From: Andrew Harvey 
> Sent: Tuesday, 24 April 2018 17:01
> To: OSM Australian Talk List 
> Subject: Re: [talk-au] Am I doing intersections right?
> 
> > I agree, if there if is not named via a sign or otherwise on the
> > ground then I would leave the name field on the link road empty.
> > Routers should be able to work out the best instructions to give
> > without a name on the link via the network already.
> 
> I fully agree that that's the way it should be, unfortunately the
> routers don't seem to always get it right:
> 
> https://www.openstreetmap.org/directions?engine=osrm_car=-
> 27.24200%2C153.02386%3B-27.24130%2C153.02422
> 
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



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

[OSM-talk-ie] OSGeo IE 2018 Symposium - Portlaoise, May 25th 2018

[Peter Mooney]

Hello everyone,

We have a full draft programme available for the 2nd annual OSGeo IE
Symposium next month in Portlaoise. See [1]
https://wiki.osgeo.org/wiki/Ireland/Symposium2018

OSM has popped up as a topic in some of the lightning talks.

Just to let you know that our early bird ticket price of €45 closes at the
end of this month.

We'll be distributing a rather simple conference pack to delegates at the
event - are there any flyers or brouchers for OpenStreetMap Ireland that
might be of interest to the audience at this event? We'd be happy to
include them in the conference pack.

Best wishes,

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

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Cascafico Giovanni]

Ho  abilitato la revisione anche per i distributori senza match su OSM (pin
verdi)


Il 17 apr 2018 2:31 PM, "Cascafico Giovanni"  ha
scritto:

> La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
> (includendo anche i waterway=fuel).
> Nella procedura di import è successivamente previsto un "audit"
> (revisione) dei risultati, come illustrato in questo [1] schema.
>
> A mio parere non è necesario validare tutti i 20709 nodi per proseguire
> nell'import, ma la revisione della comunità è comunque un passo importante.
>
> Effettuare una revisione collaborativa è abbastamza semplice: si va alla
> pagina del progetto di audit [2].
>
> __
>
> SEGNAPOSTO AZZURRI:
> distributori già presenti in OSM. Si potrà scegliere:
>
> - fixme (opzionale)
> una breve nota dei problemi (per esempio il distributore in OSM è spostato
> rispetto immagine aerea)
>
> - Good
> si accettano le modifiche dei tag evidenziati in verde, mentre la
> posizione rimane invariata
>
> - Don't change
> non fa niente e passa al prossimo
>
> - Skip
> esclude il record del MISE dall'import
>
> SEGNAPOSTO VERDI:
> distributori non presenti in OSM. Si potrà scegliere:
>
> - fixme (opzionale)
> una breve nota dei problemi
>
> - Good
> inseriti nella posizione e con in tag elencati
>
> - Duplicate
> segnala già presente (non intercettato dalla conflation perchè fuori dal
> raggio impostato)
>
> - Not there
> non si vede in giro
>
> - Skip
> esclude il recod del MISE dall'import
> __
>
> Queste validazioni hanno come unico scopo generare un file audit.json da
> applicare al secondo passo della conflation e produrre il file .osm pronto
> per l'upload.
>
>
>
>
> [1] https://wiki.openstreetmap.org/w/images/thumb/f/fe/Conflate_audit_
> chart.jpg/800px-Conflate_audit_chart.jpg
> [2] http://audit.osmz.ru/project/IFS
>
>
>
>
>
>
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sundial Atlas Mobile

[Ivo Reano]

il db è costituito da un gpx con i luoghi e da una o più cartelle con le
immagini JPG?
I waypoint sono chiamati in modo da essere collegabili alle foto?
Se il tuo database soddisfa questi criteri si può fare il tutto in modo
abbastanza semplice.

Il mio risultato lo puoi vedere da questa query overpass:
http://overpass-turbo.eu/s/yap
​dove si vedono i piloni votivi nel comune di Viù (Torino).
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Sarlat lance une campagne d'adressage "1 rue=1 nom"

[gwentux]

bonjour

je viens de repérer cette initiative de la ville de Sarlat

Sarlat fait appel à l'imagination de ses habitants pour nommer 150 rues
https://www.caissedesdepotsdesterritoires.fr/cs/ContentServer?pagename=Territoires/Articles/Articles=1250280966813

Bonne lecture !

Gwen

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

Re: [Talk-pt] Talk-pt Digest, Vol 99, Issue 2

[Nuno Caldeira]

Boa contribuição David.

Cumprimentos,

Nuno Caldeira

A terça, 24/04/2018, 13:00, <talk-pt-requ...@openstreetmap.org> escreveu:

> Send Talk-pt mailing list submissions to
> talk-pt@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-pt
> or, via email, send a message with subject or body 'help' to
> talk-pt-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-pt-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-pt digest..."
>
>
> Today's Topics:
>
>1. Levantamento funcional Cascais (David Vale)
>
>
> --
>
> Message: 1
> Date: Tue, 24 Apr 2018 12:20:39 +0100
> From: David Vale <dv...@fa.ulisboa.pt>
> To: talk-pt@openstreetmap.org
> Subject: [Talk-pt] Levantamento funcional Cascais
> Message-ID:
> <
> caa9cokck_eet7eszx7yavrok3jst2jbfnf8ju_ajngi46u4...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Bom dia
>
> Queria apenas avisar que, no âmbito do trabalho de grupo da unidade
> curricular "Geografia Urbana" do mestrado integrado em Arquitectura, os
> alunos estão a realizar um levantamento funcional do r/c dos edificios do
> concelho de Cascais. Assim, devem ter reparado que temos vários novos
> utilizadores registados recentemente, e queria avisar que nas próximas
> semanas iremos ter um registo eventualmente anormal de novas edições no
> OSM, que corresponderão à introdução desta informação no OSM.
>
> Quero com isto sensibilizar os alunos para a importância de contribuirem
> para o OSM mas também que posteriormente todos possam utilizar a
> informação. A recolha foi feita por zona (cada aluno ficou responsável por
> um deteminado local - quadrícula - do concelho de Cascai), mas depois
> iremos trabalhar com o conjunto de dados total.
>
> Obrigado e cumprimentos,
> David Vale
> Assistant Professor
> Lisbon School of Architecture - University of Lisbon
> Rua Sá Nogueira, 1349-063 Lisboa- Portugal
> T: (351) 213 615 067 F: (351) 213 625 138
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-pt/attachments/20180424/00ee6d6d/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
> --
>
> End of Talk-pt Digest, Vol 99, Issue 2
> **
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-pt] Levantamento funcional Cascais

[David Vale]

Bom dia

Queria apenas avisar que, no âmbito do trabalho de grupo da unidade
curricular "Geografia Urbana" do mestrado integrado em Arquitectura, os
alunos estão a realizar um levantamento funcional do r/c dos edificios do
concelho de Cascais. Assim, devem ter reparado que temos vários novos
utilizadores registados recentemente, e queria avisar que nas próximas
semanas iremos ter um registo eventualmente anormal de novas edições no
OSM, que corresponderão à introdução desta informação no OSM.

Quero com isto sensibilizar os alunos para a importância de contribuirem
para o OSM mas também que posteriormente todos possam utilizar a
informação. A recolha foi feita por zona (cada aluno ficou responsável por
um deteminado local - quadrícula - do concelho de Cascai), mas depois
iremos trabalhar com o conjunto de dados total.

Obrigado e cumprimentos,
David Vale
Assistant Professor
Lisbon School of Architecture - University of Lisbon
Rua Sá Nogueira, 1349-063 Lisboa- Portugal
T: (351) 213 615 067 F: (351) 213 625 138
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-GB] Nottingham Pub Meeting tonight

[SK53]

Just the usual reminder that it is the regular Nottingham/East Midlands pub
meeting tonight: https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup


To do something a little different for pre-pub mapping we will be meeting
at the Left Lion outside the Council House at 18:30. The idea is to more
systematically check POIs in the City Centre (e.g., on a quarterly basis
associated with the pub meeting)..

To this end I ahve been working over the last couple of days to find a way
to generate a '1-D' view of each street in the city centre. I'm reasonably
pleased at how far I've got (a list of named POIs, distance along street
from origin point & whether on left or right), although some additional
work is required to format this to be usable in the field. Available as a
CSV on my Dropbox account:
https://www.dropbox.com/s/soc802n8ynn53s7/nottingham_pois_by_road.csv?dl=0

Regards,

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

Re: [Talk-it] osm2pgsql su windows

[Roberto Brazzelli]

Ciao Franceso, ok chiaro ma per quanto riguarda la
sola rendirazzione dei dati per mappa web avrei delle
funzione in più rispetto ad inserire i dati in qgis come
vettore in locale?
Sto cercando soluzioni alternative a mapbox (che è indietro
con aggiornamenti da osm) e a maputnik (non riesco ad
applicare mio stile a file.mbtiles con plugin qgis "add vectors tiles 
reader").


Per postres invece .io ho un server debian (soluzione cloud) che uso
per pubblicare mappe con lizmap..potrei isntallare postgis e anche
osm2pgsql? corretto?

Rigrazie!
Roberto


Il 23/04/2018 18:05, Francesco Frassinelli ha scritto:
Il giorno 23 aprile 2018 17:45, Roberto Brazzelli 
> ha scritto:


Sto provando varie soluzioni per renderizzare i dati di osm
ma non ho ancora ben chiara la differenza tra il formato .osm
e .pfb (sono gli stessi dati solo compressi?)


Stessi dati. Il primo è basato su XML, il secondo è binario, più compatto.

Il vantaggio che avrei a caricare i dati  su db osm2pgsql è
solo quello di poter caricare grande aree?


Puoi interrogare il database* ed estrapolare ogni tipo di dato che 
desideri: porzioni di spazio, specifiche features, statistiche, 
eccetera. Potresti anche interrogare XML con strumenti come XQuery e 
maneggiarlo con XSLT., ma le performance sarebbero terribili e non 
credo si possano fare query geospaziali o indicizzazione (al più 
abbinandolo ad un database SQL). Inutile dire che senza indicizzazione 
ogni interrogazione non triviale richiederebbe una marea di tempo.


Buona serata,
Frafra

P.S. Sconsiglio di usare PostgreSQL su Windows (è testato solo sulla 
versione server, puoi avere problemi con antivirus, hai un numero 
massimo sul numero di connessioni in contemporanea, e limitazioni 
varie). In generale, sconsiglio di usare Windows :-D



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


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

Re: [OSM-talk-fr] Désabonnement de la liste

[marc marc]

il faut 3 conditions simultanées pour que le problème se produise :
- des emails "entrant" (= des personnes qui écrivent avec un FROM) 
venant d'un domaine ayant un DKIM/DMARC qui impose le rejet des emails 
modifés (par exemple yahoo).
Sur talk-be je ne me souviens pas avoir vu un email "from yahoo" 
récement, le problème ne peux donc pas se produire sur talk-be.
ET
- une config de ml qui casse ce DKIM (j'ignore si talk-be une config 
différence de talk-fr, le plus facile serrait d'écrire un email depuis 
yahoo vers talk-be).
ET
- un destinataire chez un fournisseur sans nuance (ex gmail).

pour les conditions 1 et 3, il n'est pas impossible que leur nombre 
influence aussi pour atteindre le seuil jugé "trop" par gmail.

et en plus il y a d'autres différences entre talk-be et talk-fr.
le dernier email de yahoo vers talk-fr a été envoyé depuis nabble
ce qui casse aussi le spf
cela augmente encore le risque de froisser G tout en étant obscur.

bref j'arrête ici de débuger un ansispam propriétaire...
ce n'est pas une solution...
les seules choses améliorable sont :
- la config de la liste si quelqu'un est admin de la liste et/ou veux 
faire un ticket infra osm.org sur github
- la part de responsabilité des utilisateurs concernés quand au choix 
d'un fournisseur fermé ou ouvert, y compris dans les scores antispam.

Le 24. 04. 18 à 10:28, osm.sanspourr...@spamgourmet.com a écrit :
> Peut-être que les paramètres des autres listes ont été ajustés comme suggéré 
> par ailleurs et pas cette liste-ci.
> 
> Jean-Yvon
> 
> 
>> Gesendet: Dienstag, 24. April 2018 um 07:26 Uhr
>> Von: "Marc Gemis - marc.ge...@gmail.com"
>> Mais la seule liste d'OpenStreetMap qui donne des problème c'est
>> talk-fr. Pas de problèmes avec talk, talk-be, talk-gb, tagging,
>> talk-au ...
>>
>> m.
> 
> 
> ___
> 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] Sidewalk symmetry

[Ed Loach]

Clifford wrote:

> There is a good website that explains the separate way approach 
> http://opensidewalks.com
> I know the people who put it together and they convinced me it's the better 
> approach.

I would say separate ways make more sense in urban USA where you can't cross 
the road just anywhere, see e.g.
http://news.bbc.co.uk/1/hi/6251431.stm

In the UK I would use sidewalk tags where the pavement (sidewalk) is only 
separated from the road by a kerb, and separate ways where there is something 
more (such as grass verge or fence or whatever). In the cases of verges I would 
then make sure private driveways, etc that cross the footpath are mapped so 
pedestrians can see the obvious places to cross without getting their shows wet 
should the grass be wet. You can still do things like sidewalk:surface if you 
want, and it appears many do:
https://taginfo.openstreetmap.org/search?q=sidewalk
Otherwise you start needing relations to show where separate sidewalk and road 
ways allow you to cross, or put arbitrary joining ways at intervals. Admittedly 
this method of mapping doesn't cope with the situation where there is a verge 
so narrow you can step across it without stepping on the grass.

Ed 



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

Re: [Talk-cz] Data ze ZÚ

[Honza Cibulka]

Zdar,
je to trochu složitější: prostorová data ve smyslu zákona o právu na informace 
o životním prostředí může stát zpřístupňovat na základě nevýhradní licenční 
smlouvy [1], která může stanovit podmínky jejich využití, jako i cenu za 
zpřístupnění těch informací. Takže to není nic jako úřední dílo. Soud řekl, že 
zde nejsou autorská práva třetích stran, např. soukromých firem, která by 
bránila poskytnutí těch informací veřejnosti.

Jde tedy o dvě otázky: 

- jak vysokou částku si může úřad (ZÚ) za data účtovat?
- jak restriktivní může být licence (když si to koupim, můžu z toho 
trasovat do OSM)?

No a na to není žádnej úplně jasnej návod. V případě ceny zákon stanoví [2], že 
za data "může být požadována úhrada ve výši, která nepřesáhne minimální výši 
nezbytnou k zajištění potřebné kvality a zpřístupňování prostorových dat". Což 
je přesně kolik? Patří do toho i náklady na pořízení těch dat? Náklady na 
geoportál? Výkladová literatura ani judikatura na tuhle otázku (aspoň kam sahaj 
moje znalosti) spíš neodpovídá. Zkrátka proto, že doposaváde všichni platili, 
co si ZÚ účtoval, a nikdo do toho nešťoural. Můj pohled na věc jsem naznačil v 
blogu [3], ale závazně to bude vykládat nejdřív ZÚ, pak ČÚZK a pak možná zas 
soud.

K licenci pak zákon stanoví [4], že "podmínky poskytnutí informace v licenční 
nebo podlicenční smlouvě musí umožňovat další užití informace žadatelem v 
souladu se žádostí", takže teoreticky v žádosti by člověk měl uvést, že z dat 
hodlá trasovat do OSM a licence by s tím měla počítat. Imho pak z textu zákona 
neplyne, že by ZÚ mohl s ohledem na účel stanovený v licenci navýšit cenu, ale 
zase, závazně to vyloží někdo jinej.

V obou případech se to týká poskytnutí na žádost, věcí vyvěšených na 
prohlížecích službách se to netýká. Zda tedy úřad může stanovit licencí 
mantinely pro využití prohlížecích služeb a co všechno může uživatelům zakázat 
(aby to nebyla svévole), taky nevíme. ZÚ tu licenci soudně nevymáhá (ptal jsem 
se na právnim, prej to nikdy neudělali, takže co si kdo ukradne, to má), akorát 
občas zablokujou přístupy z nějaký IP.

Osobně si myslim, že všechny tyle otázky se měly už dávno zodpovědět v rámci 
GeoInfoStrategie [5] a navazujících projektů, jenže tam se řešej důležitejší 
věci [6]. Takže zbejvá průzkum bojem (litigací).

Honza Cibulka

[1] https://www.zakonyprolidi.cz/cs/1998-123/zneni-20150901#p11c-1
[2] https://www.zakonyprolidi.cz/cs/1998-123/zneni-20150901#p11c-3
[3] http://gismentors.cz/blog/soud-nastavil-mantinely-cenam-dat-ze-zu/
[4] https://www.zakonyprolidi.cz/cs/1999-106/zneni-20170801#p14a-3
[5] http://www.mvcr.cz/clanek/geoinfostrategie.aspx
[6] https://giphy.com/gifs/gal-gadot-6J6QQ8Rc2IaKQ


-Original Message-
From: Pavel Machek  
Sent: úterý 24. dubna 2018 10:54
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Data ze ZÚ

Ahoj!

> jelikož se rozhodnutím soudu [1] zas dal do pohybu spor o data ZÚ, měl 
> bych volně související teoretickou otázku: jaké datové sady 
> Zeměměřického úřadu [2] by pro tuzemské OSM byly nejpřínosnější?
> Proč? A funguje něco takového v zahraničí?

>  http://gismentors.cz/blog/soud-nastavil-mantinely-cenam-dat-ze-zu/

Dobre zpravy :-).

Pokud soud rozhodl ze autorska prava na data ZU nalezi statu, znamena to ze je 
to uredni dilo, mohou se libovolne kopirovat / pouzivat? To by byla dobra 
zprava, protoze bez ohledu na to co si ZU uctuje by bylo mozne data koupit 
jednou a pak je proste vystavit na ftp... (pripadne ukecat nekoho kdo uz data 
zakoupil aby poskytl kopii na ftp / DVD...)

A ortofoto je tady: http://geoportal.cuzk.cz/geoprohlizec/?wmcid=2012
Pokud na nem neni ochrana podle autorskeho zakona, tak nam nic nebrani ho 
stahnout a zacit pouzivat pro odvozovani...

Jako nejprinosnejsi bych urcite videl ortofoto. Dal bych rad videl digitalni 
model terenu a mapu lesnich cest.

Pavel

> [2] 
> http://geoportal.cuzk.cz/(S(003ek0o14b2nafrrkyz5oamk))/Default.aspx?mo
> de=eShop_tab=sekce-01-gp=13#
> 
> Jan Cibulka
>  
> tel. 776 307 158
> http://datastory.cz

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


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Talk-it] osm2pgsql su windows

[Roberto Brazzelli]

Ciao, non intendo fare editing dei dati ma solo rederizzarli
per inseririrli in mappa web..forse mi son espresso male.
A quanto leggo sulla wiki sembra che uno dei modi sia
caricari i dati di osm su db e poi con mapnik procedere
con gli sitli.

Rigrazie

Il 23/04/2018 22:33, emmexx ha scritto:

On 04/23/2018 05:45 PM, Roberto Brazzelli wrote:

Il vantaggio che avrei a caricare i dati  su db  osm2pgsql è
solo quello di poter caricare grande aree?

Caricare i dati su un database non credo ti serva per fare editing dei
dati, cioè non è un modo alternativo a josm.

ciao
maxx



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

Re: [talk-au] Am I doing intersections right?

[Michael]

Ok it seems the OSM website will not centre you on an area from a link but 
takes you back to the last area you looked at.

Now ... I have removed 2 tags from the slip lane sections.


-Original Message-
From: Michael  
Sent: Tuesday, 24 April 2018 7:13 PM
To: 'OSM Australian Talk List' 
Subject: Re: [talk-au] Am I doing intersections right?

For some reason it wont show me the location of the pins when I go to that link.

I had looked at that area once before and noticed some odd stuff in josm but 
left it alone.

I've gone back in with josm and made some changes, if the routing starts 
working (note sure on caching times before we see it) then I would call it 
fixed.



-Original Message-
From: osm.talk...@thorsten.engler.id.au 
Sent: Tuesday, 24 April 2018 6:46 PM
To: 'OSM Australian Talk List' 
Subject: Re: [talk-au] Am I doing intersections right?

From: Andrew Harvey 
Sent: Tuesday, 24 April 2018 17:01
To: OSM Australian Talk List 
Subject: Re: [talk-au] Am I doing intersections right?

> I agree, if there if is not named via a sign or otherwise on the 
> ground then I would leave the name field on the link road empty.
> Routers should be able to work out the best instructions to give 
> without a name on the link via the network already.

I fully agree that that's the way it should be, unfortunately the routers don't 
seem to always get it right:

https://www.openstreetmap.org/directions?engine=osrm_car=-27.24200%2C153.02386%3B-27.24130%2C153.02422



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


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


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

Re: [talk-au] Am I doing intersections right?

[Michael]

For some reason it wont show me the location of the pins when I go to that link.

I had looked at that area once before and noticed some odd stuff in josm but 
left it alone.

I've gone back in with josm and made some changes, if the routing starts 
working (note sure on caching times before we see it) then I would call it 
fixed.



-Original Message-
From: osm.talk...@thorsten.engler.id.au  
Sent: Tuesday, 24 April 2018 6:46 PM
To: 'OSM Australian Talk List' 
Subject: Re: [talk-au] Am I doing intersections right?

From: Andrew Harvey 
Sent: Tuesday, 24 April 2018 17:01
To: OSM Australian Talk List 
Subject: Re: [talk-au] Am I doing intersections right?

> I agree, if there if is not named via a sign or otherwise on the 
> ground then I would leave the name field on the link road empty. 
> Routers should be able to work out the best instructions to give 
> without a name on the link via the network already.

I fully agree that that's the way it should be, unfortunately the routers don't 
seem to always get it right:

https://www.openstreetmap.org/directions?engine=osrm_car=-27.24200%2C153.02386%3B-27.24130%2C153.02422



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


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

Re: [Talk-cz] Data ze ZÚ

[Pavel Machek]

Ahoj!

> jelikož se rozhodnutím soudu [1] zas dal do pohybu spor o data ZÚ,
> měl bych volně související teoretickou otázku: jaké datové sady
> Zeměměřického úřadu [2] by pro tuzemské OSM byly nejpřínosnější?
> Proč? A funguje něco takového v zahraničí?

>  http://gismentors.cz/blog/soud-nastavil-mantinely-cenam-dat-ze-zu/

Dobre zpravy :-).

Pokud soud rozhodl ze autorska prava na data ZU nalezi statu, znamena
to ze je to uredni dilo, mohou se libovolne kopirovat / pouzivat? To
by byla dobra zprava, protoze bez ohledu na to co si ZU uctuje by bylo
mozne data koupit jednou a pak je proste vystavit na ftp... (pripadne
ukecat nekoho kdo uz data zakoupil aby poskytl kopii na ftp / DVD...)

A ortofoto je tady: http://geoportal.cuzk.cz/geoprohlizec/?wmcid=2012
Pokud na nem neni ochrana podle autorskeho zakona, tak nam nic nebrani
ho stahnout a zacit pouzivat pro odvozovani...

Jako nejprinosnejsi bych urcite videl ortofoto. Dal bych rad videl
digitalni model terenu a mapu lesnich cest.

Pavel

> [2] 
> http://geoportal.cuzk.cz/(S(003ek0o14b2nafrrkyz5oamk))/Default.aspx?mode=eShop_tab=sekce-01-gp=13#
> 
> Jan Cibulka
>  
> tel. 776 307 158
> http://datastory.cz

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


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-be] Crab Addr import tool

[Glenn Plas]

On 23-04-18 13:29, Sus Verhoeven wrote:
> Ik gebruik altijd de laatste versie van JOSM, nu 13576.
> Ik ben wel een tijdje inactief geweest.

Verklaart het idd, ook waarom ik het ook voorheb, ik gebruik ook steeds
de laatste versie en kon het probleem reproduceren.

Morgen doe ik een nieuwe data run van de address gegevens.

Glenn


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

[OSM-talk-fr] Paris Soirée de Contribution au Libre

[Nicolas Bétheuil]

Hey,

kiki viendra ?
https://www.agendadulibre.org/events/16717

Je pense bosser sur les défibrillateurs de France & Navarre

A partir de https://www.data.gouv.fr/fr/search/?q=defibrillateur
Christian a déjà couvert Paris
https://twitter.com/cq94/status/988451160272011265
J'ai ajouté Issy ce matin là https://www.mapcontrib.xyz/t/7f46aa-Defibrillateur

Voir ce qu'on peut faire dessus
Des avis ?

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

Re: [talk-au] Am I doing intersections right?

[osm.talk-au]

From: Andrew Harvey  
Sent: Tuesday, 24 April 2018 17:01
To: OSM Australian Talk List 
Subject: Re: [talk-au] Am I doing intersections right?

> I agree, if there if is not named via a sign or otherwise 
> on the ground then I would leave the name field on the link 
> road empty. Routers should be able to work out the best 
> instructions to give without a name on the link via the network 
> already.

I fully agree that that's the way it should be, unfortunately the routers don't 
seem to always get it right:

https://www.openstreetmap.org/directions?engine=osrm_car=-27.24200%2C153.02386%3B-27.24130%2C153.02422



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

Re: [OSM-talk-fr] Désabonnement de la liste

[osm . sanspourriel]

Peut-être que les paramètres des autres listes ont été ajustés comme suggéré 
par ailleurs et pas cette liste-ci. 

Jean-Yvon


> Gesendet: Dienstag, 24. April 2018 um 07:26 Uhr
> Von: "Marc Gemis - marc.ge...@gmail.com"
> Mais la seule liste d'OpenStreetMap qui donne des problème c'est
> talk-fr. Pas de problèmes avec talk, talk-be, talk-gb, tagging,
> talk-au ...
> 
> m.


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

Re: [talk-au] Am I doing intersections right?

[Andrew Harvey]

On 24 April 2018 at 14:28, Alex Sims  wrote:

> You might be mapping for the renderer. :)
>
> I have been not giving slip roads a name and making sure they are
> highway=secondary_link, trunk_link etc, which is considered valid by Keep
> Right, Geofabrik etc. It also makes sense on the ground as there is no
> physical sign on the slip road to give its name, it has none.
>
> This then works correctly when using mkgmap and putting the data on a
> Garmin GPS.
>

I agree, if there if is not named via a sign or otherwise on the ground
then I would leave the name field on the link road empty. Routers should be
able to work out the best instructions to give without a name on the link
via the network already.

This is in line with the wiki at
https://wiki.openstreetmap.org/wiki/Highway_link#Tagging

Link roads normally do not have names. Please use the destination=* and its
> extensions tag to give the cross-street's ref=* and signed destinations
> such as a city or the name of the destination street, so that routing
> engines can correctly announce the exit to the "name or ref of the
> destination street" as you enter the _link.


It looks like these are "At-grade intersections"
https://wiki.openstreetmap.org/wiki/Highway_link#At-grade_intersections
says "Here too it probably makes more sense to consider the links as
"belonging" to the more major highway." so I've always been giving link
roads the classification of higher class road they are connected with, ie.
in your example all 4 would be trunk_link.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au