Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[Marc Gemis]

We had a similar discussion on the ring around Roeselare on the
Riot/Matrix channel.

Maybe it's time we rewrite the Belgian highway classification page to
indicate that Nxxx & Rxxx are just indications for mapping and that
traffic signs and road importance take precedence ?

m

On Fri, Jan 19, 2018 at 8:44 AM, OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Thanks for the link. I hadn't discovered this page yet.
>
> On the other hand, the same page reads "Rx should also be tagged as 
> motorways".
>
> R0 Brussels, R1 Antwerp and R4 Ghent are tagged like that.
>
> But R24 Nivelles, R20 Brussels, R9 Charleroi are tagged as trunks.
>
> And R52 Tournai, R36 Kortrijk and R30 Brugge as primary.
>
> And parts of R23 Leuven are tagged as primary and some other even as 
> secondary.
>
> So, it seems nuance, interpretations and findings from the ground lead to 
> different tagging of R roads.
>
> -Original Message-
> From: Marc Gemis [mailto:marc.ge...@gmail.com]
> Sent: Friday, January 19, 2018 07:16
> To: OpenStreetMap Belgium 
> Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation 
> route=bicycle
>
> I think 
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
> gives the solution, there needs to be an F9 sign. If not, it is a primary.
>
> regards
>
> m
>
> On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>> Hello,
>>
>> Can you help with the B) part of the discussion ?
>>
>> What highway value is suitable for R50 ?
>>
>> Now that I discovered the local implicit characteristics thanks to the
>> answer to question A), trunk is probably right, but I wanted to ask
>> your views nonetheless.
>>
>> Thx.
>> 
>> From: Volker Schmidt
>> Sent: ‎18-‎01-‎18 09:39
>> To: Tag discussion, strategy and related tools
>> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>>
>> I suppose Osmose uses the country specific tables in [1] The table for
>> Belgium states that bicycle=no is implicit for "highway=trunk".
>> Hence the short way in question would need to have the additional tag
>> "bicycle=yes" for bicycle routing to pass along that cycle lane.
>> The road signs out there seem to be consistent, there are "no-bicycle"
>> sign along the ring road, except for this short piece.
>>
>> Your second point regarding the road classification trunk is a
>> different issue, that needs to be discussed with the Belgian community.
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restri
>> ctions
>>
>> On 17 January 2018 at 22:45, OSMDoudou
>> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> This is a two-fold question in fact.
>>>
>>>
>>>
>>> (A)
>>>
>>>
>>>
>>> Osmose raises error "Way access mismatch relation route=bicycle" [1]
>>> on a segment of the R50 highway [2] [3].
>>>
>>>
>>>
>>> I'm guessing it's because the segment is part of relation for a bike
>>> route but it's tagged as trunk (as the rest of R50), and a trunk
>>> would imply a restriction for bicycles.
>>>
>>>
>>>
>>> Although, I see such an implication for motorways [4], I don't see it
>>> for trunks [5].
>>>
>>>
>>>
>>> Do you know what causes the access mismatch, because I don't see it
>>> from the tags ?
>>>
>>>
>>>
>>> (B)
>>>
>>>
>>>
>>> This issue raises the question whether R50 should be tagged as trunk
>>> in the first place.
>>>
>>>
>>>
>>> The Wiki page [6] refers to notions like "high performance" and road
>>> signs F9. But the road is limited to 70 km/h and there are no F9
>>> signs on the entries and exits of R50, only C19 "No entry for
>>> pedestrians" and C11 + C9 "No entry for bicycles" + "No entry for
>>> mopeds (and mofas)", which tend to confirm it's not a trunk.
>>>
>>>
>>>
>>> I wonder if primary wouldn't be more accurate classification,
>>> although the Wiki refers to a "highway linking large towns" [7],
>>> which is not the case here as the highway is a ring around the city not a 
>>> road between cities.
>>>
>>>
>>>
>>> What type of road would you qualify the entire R50 ?
>>>
>>>
>>>
>>> Thx.
>>>
>>>
>>>
>>> [1] http://osmose.openstreetmap.fr/en/error/15216104253
>>>
>>> [2] http://www.openstreetmap.org/browse/way/251684307
>>>
>>> [3] https://goo.gl/maps/khpwvm8kxQw
>>>
>>> [4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
>>>
>>> [5] https://wiki.openstreetmap.org/wiki/Trunk
>>>
>>> [6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
>>>
>>> [7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
> 

Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[OSMDoudou]

Thanks for the link. I hadn't discovered this page yet.

On the other hand, the same page reads "Rx should also be tagged as motorways".

R0 Brussels, R1 Antwerp and R4 Ghent are tagged like that.

But R24 Nivelles, R20 Brussels, R9 Charleroi are tagged as trunks.

And R52 Tournai, R36 Kortrijk and R30 Brugge as primary.

And parts of R23 Leuven are tagged as primary and some other even as secondary.

So, it seems nuance, interpretations and findings from the ground lead to 
different tagging of R roads.

-Original Message-
From: Marc Gemis [mailto:marc.ge...@gmail.com] 
Sent: Friday, January 19, 2018 07:16
To: OpenStreetMap Belgium 
Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

I think 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
gives the solution, there needs to be an F9 sign. If not, it is a primary.

regards

m

On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Hello,
>
> Can you help with the B) part of the discussion ?
>
> What highway value is suitable for R50 ?
>
> Now that I discovered the local implicit characteristics thanks to the 
> answer to question A), trunk is probably right, but I wanted to ask 
> your views nonetheless.
>
> Thx.
> 
> From: Volker Schmidt
> Sent: ‎18-‎01-‎18 09:39
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>
> I suppose Osmose uses the country specific tables in [1] The table for 
> Belgium states that bicycle=no is implicit for "highway=trunk".
> Hence the short way in question would need to have the additional tag 
> "bicycle=yes" for bicycle routing to pass along that cycle lane.
> The road signs out there seem to be consistent, there are "no-bicycle" 
> sign along the ring road, except for this short piece.
>
> Your second point regarding the road classification trunk is a 
> different issue, that needs to be discussed with the Belgian community.
>
> [1]
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restri
> ctions
>
> On 17 January 2018 at 22:45, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>
>> Hello,
>>
>>
>>
>> This is a two-fold question in fact.
>>
>>
>>
>> (A)
>>
>>
>>
>> Osmose raises error "Way access mismatch relation route=bicycle" [1] 
>> on a segment of the R50 highway [2] [3].
>>
>>
>>
>> I'm guessing it's because the segment is part of relation for a bike 
>> route but it's tagged as trunk (as the rest of R50), and a trunk 
>> would imply a restriction for bicycles.
>>
>>
>>
>> Although, I see such an implication for motorways [4], I don't see it 
>> for trunks [5].
>>
>>
>>
>> Do you know what causes the access mismatch, because I don't see it 
>> from the tags ?
>>
>>
>>
>> (B)
>>
>>
>>
>> This issue raises the question whether R50 should be tagged as trunk 
>> in the first place.
>>
>>
>>
>> The Wiki page [6] refers to notions like "high performance" and road 
>> signs F9. But the road is limited to 70 km/h and there are no F9 
>> signs on the entries and exits of R50, only C19 "No entry for 
>> pedestrians" and C11 + C9 "No entry for bicycles" + "No entry for 
>> mopeds (and mofas)", which tend to confirm it's not a trunk.
>>
>>
>>
>> I wonder if primary wouldn't be more accurate classification, 
>> although the Wiki refers to a "highway linking large towns" [7], 
>> which is not the case here as the highway is a ring around the city not a 
>> road between cities.
>>
>>
>>
>> What type of road would you qualify the entire R50 ?
>>
>>
>>
>> Thx.
>>
>>
>>
>> [1] http://osmose.openstreetmap.fr/en/error/15216104253
>>
>> [2] http://www.openstreetmap.org/browse/way/251684307
>>
>> [3] https://goo.gl/maps/khpwvm8kxQw
>>
>> [4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
>>
>> [5] https://wiki.openstreetmap.org/wiki/Trunk
>>
>> [6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
>>
>> [7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>>
>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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


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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Michael Collinson]

Hi Micah,

I think you came up with a good answer to your conundrum in an earlier 
post in this thread: Don't explain what an optimal changeset IS, explain 
what it is NOT:


Something like:

"It helps other contributors understand your edits if you group what you 
are doing in a local area into one changeset. For example, if you are 
creating the outlines of 20 buildings, group them into one changeset. On 
the other hand, if you are adding 3 POIs, (points of interest),  that 
are 1000 km apart in different countries, then it is more useful to put 
them into 3 changesets. Of course, if you are creating the outlines of 
1,000 buildings in your town, you do not have to do them all at once!


If you worried about losing your data, our data editor software allows 
you to make incremental saves to the OSM server as you go along. iD does 
this automatically. Potlatch and JOSM have buttons that allow you to 
save partial work into a changeset and then keep adding to it until you 
are done."


[This could probably be improved for readability by non-native English 
speakers. And the editor text should be fact checked, I am a die-hard 
Potlatch user.]



Mike

(first post for a long, long time)


On 1/17/18 4:13 PM, Micah Brzozowski wrote:
Certainly I am not intending to change the community and require every 
mapper to comply. If you're an experienced mapper, you're fine.


I mean new users, who are not yet integrated with the community. Their 
work should be checked thoroughly (in Achavi, osmcha...). All novices 
make mistakes, after all. Better to give them good habits. By 
extension, smaller number of changeset will lead to less recycling of 
same changeset comments.


I made this thread because I found it difficult to convey what is best 
practice in short form in changeset comments.


Maybe I should simplify things when explaining to them? No need to 
tell all the conventions, just what is a good start - but hoping it 
won't backfire ;)


17.01.2018 3:35 PM "Imre Samu" > napisał(a):


>  one changeset per building, repeated 20 times

my typical use case:   House numbering on the street: push the
numbers & forget & go to the next house    ( fast feedback loop
vs. Delayed gratification  )
- sometimes the mobil app is crashing, and I don't want to go back
100m to re-enter - the last 5-10 numbers


> Obviously this makes them PITA to review quickly in Achavi or
whatever tool you use.

imho: it is easier to group the changeset on the reviewer side : 
by user + by hour   ( group by user, hour )   than change the
community.

Imre





2018-01-17 15:13 GMT+01:00 Michał Brzozowski >:

Certainly not:
- one changeset per building, repeated 20 times
- one changeset for 3 POIs that are 1000 km apart in different
countries

These are real world examples. In the latter Achavi can often
refuse to run.

That's also why I asked ;-) It's not that easy to formulate
the answer what is reasonable to include in a changeset.

Michał

17.01.2018 2:54 PM "Tobias Zwick" > napisał(a):

So, what is the optimal changeset size, and why?

Tobias

On 17/01/2018 14:26, Michał Brzozowski wrote:
> Many new users have a habit of e.g. sending one or few
objects per
> changeset, resulting in a dozen or even more changesets
per day.
> Obviously this makes them PITA to review quickly in
Achavi or whatever
> tool you use.
>
> This habit is probably caused by non-knowledge of how
auto-save works in
> iD (which makes the work reasonably secure), as well as
just not knowing
> better thus forming their own judgement.
>
> How should we teach about optimal changeset size? This
is quite tricky -
> how we would define it?
>
> Can the iD nudge users towards better practice? (Linking
to Good
> changeset comments wiki page would be useful as well)
>
> Michał
>
>
> ___
> 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-it] pronto soccorso ospedali italiani

[cesare gerbino]

Grazie!


Cesare Gerbino

http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b

Questo è un account di posta personale di Cesare Gerbino: tutte le opinioni
espresse sono personali e non riflettono necessariamente quelle del mio
datore di lavoro

This is Cesare Gerbino mail account. Text is written by Cesare Gerbino:
 the views expressed  are mine and not necessarily those of my employer.
.


2018-01-19 7:59 GMT+01:00 Aury88 :

> ricordo che esiste il tag healthcare:speciality=emergency
>
>
>
> -
> Ciao,
> Aury
> --
> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] Deserts, mapping and sources

[cleary]

I agree that it would be useful to map deserts. The boundaries may be inexact 
and landcover is quite variable but they are geographic regions that users may 
occasionally search for, and they are major features of inland Australia.  
However I don't yet know of a source we could use. 



On Wed, Jan 17, 2018, at 10:49 AM, Warin wrote:
> Hi,
> 
> OSMand has started rendering deserts.
> 
> I note that only the Simpson Desert in OSM so far is Way: Simpson Desert 
> (168949121) ... I cannot find the source for this.
> 
> It would be nice to map the other deserts that we have too. A good 
> source for this would be the 'Interim Biogeographic Regionalisation for 
> Australia' by the Australian Government's Department of Sustainability, 
> Environment, Water, Population and Communities. Of course that copyright 
> is given as 'CC by' ... See the second map in 
> https://en.wikipedia.org/wiki/Deserts_of_Australia for reference.
> 
> Any ideas for a legally usable OSM source?
> 
> 
> 
> 
> 
> ___
> 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-it] pronto soccorso ospedali italiani

[Aury88]

ricordo che esiste il tag healthcare:speciality=emergency



-
Ciao,
Aury
--
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] Talk-pt Digest, Vol 97, Issue 2

[José António Flor de Sousa]

Bom dia Nuno,

Verifico que muitas das fotos do meu mapillary mostra os sinais de transito 
errado. Ás vezes um detalhe em um arbusto é tido como um sinal de transito.

Muitas das vezes fazem o bluer em texto que seria importante destacar nas 
fotos. Refiro-me a uma bomba de gasolina em que o nome dela ficou bluer. E 
muitos mais casos. Pelo que entendi só se deve fazer o bluer a rostos de 
pessoas e matriculas e algo sensível como nudez. (sim já vi no googles street 
view um homem nu no quintal da casa dele. LOL) No googles street view eu 
apareço 3 vezes sem bluer no meu rosto. Mas isso foi no passado, agora têm 
fotos mais recentes.

Era isso ai que eu queria poder editar, recusar um sinal de transito errado e 
aceitar os correctos.


Eu já pedi o mount para carro e bicicleta, deve chegar para a semana pois já 
recebi email de confirmação de envio.

José Flor




From: Nuno Caldeira 
Sent: Thursday, 18 January 2018 1:45:24 PM
To: talk-pt@openstreetmap.org
Subject: Re: [Talk-pt] Talk-pt Digest, Vol 97, Issue 2

Bem vindo,

Se precisar de ajuda relativamente ao OSM ou Mapillary esteja à vontade.
Não entendi a sua dúvida relativamente aos sinais de trânsito. Estão a ser 
incorrectamente detectados no Mapillary ou no OSM os que estão representados 
estão incorrectos?
Caso queira um mount para utilizar o telemóvel para capturar imagens para o 
Mapillary, pode solicitar um para carro ou bicicleta, neste link 
https://docs.google.com/forms/d/1aOVJ8dvRsYahpW4k4hW4XRYGMZncmUWl4glpEr6p-pM/viewform?edit_requested=true


Em 18/01/2018 12:00 da tarde, 
> 
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. Apresentação de José Flor - OzFlor
  (José António Flor de Sousa)
   2. Re: Apresentação de José Flor - OzFlor (Nelson A. de Oliveira)
   3. Re: Apresentação de José Flor - OzFlor (Pedro Lima)
   4. Re: Apresentação de José Flor - OzFlor (Marcos Oliveira)


--

Message: 1
Date: Wed, 17 Jan 2018 12:20:37 +
From: José António Flor de Sousa 
>
To: "talk-pt@openstreetmap.org" 
>
Subject: [Talk-pt] Apresentação de José Flor - OzFlor
Message-ID:

>

Content-Type: text/plain; charset="iso-8859-1"

Bom dia ao grupo,


Sou o José Flor, o nick na internet e por ai fora é OzFlor.

Comecei recentemente na here seguido de openstreetmap e mapillary.


Ainda sou novo por aqui e aos poucos vou entendendo como se faz. Irei ter 
duvidas que procurarei informar. Assim sempre que estiver editando peço ajuda 
quando o necessitar.


Iram verificar que vou editar em 5 países porque é por ai que eu tenho andado e 
conheço as áreas em volta.


Os meus interesses são diversos, parapente ciência com astronomia sem faltar, 
montanhas e natureza em geral. Electrónica já deixei de parte onde tinha muito 
material de aulas em fóruns que agora se perderam. Meu ultimo trabalho por 
conta própria era handyman. Agora estou parado e com muito tempo para viajar 
por ai.


Ainda não sei que tipo de contribuição posso dar para o openstreetmap, conforme 
for entrando no site vou vendo se algo necessita de editar. Por agora estou 
fazendo o mapillary e verifico que tem muitos erros de sinais de transito que 
gostaria de editar nas minhas ou noutras imagens que me aparecerem pela frente.


Grato por me aceitarem no grupo.


José Flor



-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Wed, 17 Jan 2018 10:31:26 -0200
From: "Nelson A. de Oliveira" >
To: OSM Portugal >
Subject: Re: [Talk-pt] Apresentação de José Flor - OzFlor
Message-ID:

Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[Marc Gemis]

I think 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
gives the solution, there needs to be an F9 sign. If not, it is a
primary.

regards

m

On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Hello,
>
> Can you help with the B) part of the discussion ?
>
> What highway value is suitable for R50 ?
>
> Now that I discovered the local implicit characteristics thanks to the
> answer to question A), trunk is probably right, but I wanted to ask your
> views nonetheless.
>
> Thx.
> 
> From: Volker Schmidt
> Sent: ‎18-‎01-‎18 09:39
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>
> I suppose Osmose uses the country specific tables in [1]
> The table for Belgium states that bicycle=no is implicit for
> "highway=trunk".
> Hence the short way in question would need to have the additional tag
> "bicycle=yes" for bicycle routing to pass along that cycle lane.
> The road signs out there seem to be consistent, there are "no-bicycle" sign
> along the ring road, except for this short piece.
>
> Your second point regarding the road classification trunk is a different
> issue, that needs to be discussed with the Belgian community.
>
> [1]
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
>
> On 17 January 2018 at 22:45, OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>
>> Hello,
>>
>>
>>
>> This is a two-fold question in fact.
>>
>>
>>
>> (A)
>>
>>
>>
>> Osmose raises error "Way access mismatch relation route=bicycle" [1] on a
>> segment of the R50 highway [2] [3].
>>
>>
>>
>> I'm guessing it's because the segment is part of relation for a bike route
>> but it's tagged as trunk (as the rest of R50), and a trunk would imply a
>> restriction for bicycles.
>>
>>
>>
>> Although, I see such an implication for motorways [4], I don't see it for
>> trunks [5].
>>
>>
>>
>> Do you know what causes the access mismatch, because I don't see it from
>> the tags ?
>>
>>
>>
>> (B)
>>
>>
>>
>> This issue raises the question whether R50 should be tagged as trunk in
>> the first place.
>>
>>
>>
>> The Wiki page [6] refers to notions like "high performance" and road signs
>> F9. But the road is limited to 70 km/h and there are no F9 signs on the
>> entries and exits of R50, only C19 "No entry for pedestrians" and C11 + C9
>> "No entry for bicycles" + "No entry for mopeds (and mofas)", which tend to
>> confirm it's not a trunk.
>>
>>
>>
>> I wonder if primary wouldn't be more accurate classification, although the
>> Wiki refers to a "highway linking large towns" [7], which is not the case
>> here as the highway is a ring around the city not a road between cities.
>>
>>
>>
>> What type of road would you qualify the entire R50 ?
>>
>>
>>
>> Thx.
>>
>>
>>
>> [1] http://osmose.openstreetmap.fr/en/error/15216104253
>>
>> [2] http://www.openstreetmap.org/browse/way/251684307
>>
>> [3] https://goo.gl/maps/khpwvm8kxQw
>>
>> [4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
>>
>> [5] https://wiki.openstreetmap.org/wiki/Trunk
>>
>> [6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
>>
>> [7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>>
>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [talk-au] Help with licensing

[Jonathon Rossi]

> The Department will not provide the data under an Open Database license.
It is our belief that a CC:BY licence is sufficient for use of our data.

Am I missing something, I didn't think we were asking anyone to relicense
their data under the ODbL, just to accept our understanding of one clause
(Section 3(a)(1)) and waive another (Section 2(a)(5)(B)). Are DNRM
misunderstanding what we are requesting?

The second line of the waiver says:
> [Entity] waives Section 2(a)(5)(B) of the CC BY 4.0 license as to
OpenStreetMap and its users with the understanding that the Open Database
License 1.0 requires open access or parallel distribution of OpenStreetMap
data.

Section 2(a)(5)(B) says:
> No downstream restrictions. You may not offer or impose any additional or
different terms or conditions on, or apply any Effective Technological
Measures to, the Licensed Material if doing so restricts exercise of the
Licensed Rights by any recipient of the Licensed Material.

Aren't we (OSMF) just asking the copyright owner to waive their rights to
this clause to allow downstream users of the collective OSM data so that
for example it could be put on a Bluray disc. Their data would still be
CCBY licensed, and the OSM data would be a mix of ODbL and CCBY licensed
data?

/cc Simon Poole

On Fri, Jan 19, 2018 at 3:19 PM Jonathon Rossi  wrote:

> I also want to make use of the QLD DCDB and was going to start a new
> thread on the mailing list about it today to work out how to get out of
> this stalemate after Andrew Davidson informed me last week.
>
> It appears Andrew Harvey just recently had great luck with Victoria DELWP
> signing the waiver and on a corporate letterhead. AndrewH was that luck and
> are there any insights that you could assist us with here that might help
> us convince QLD DNRM?
>
> Jono
>
> On Fri, Jan 19, 2018 at 2:42 PM Andrew Davidson 
> wrote:
>
>> It's a known problem with a difference of opinion between the Queensland
>> Government and OSM as to licence compatibility. See this thread for example:
>>
>> https://www.mail-archive.com/talk-au@openstreetmap.org/msg10883.html
>>
>> On Fri, Jan 19, 2018 at 3:34 PM, Satuim <95.5.ra...@gmail.com> wrote:
>>
>>> Hey everyone,
>>>
>>> I recently asked for permission to use a CC-BY 4.0 dataset but got
>>> rejected. The dataset I want to use is fairly important (boundaries for
>>> suburbs and counties for QLD).
>>>
>>> Here is the response I got:
>>>
>>> The Department will not provide the data under an Open Database license.
>>> It is our belief that a CC:BY licence is sufficient for use of our data.
>>>
>>>
>>> ___
>> 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] Help with licensing

[Jonathon Rossi]

I also want to make use of the QLD DCDB and was going to start a new thread
on the mailing list about it today to work out how to get out of this
stalemate after Andrew Davidson informed me last week.

It appears Andrew Harvey just recently had great luck with Victoria DELWP
signing the waiver and on a corporate letterhead. AndrewH was that luck and
are there any insights that you could assist us with here that might help
us convince QLD DNRM?

Jono

On Fri, Jan 19, 2018 at 2:42 PM Andrew Davidson  wrote:

> It's a known problem with a difference of opinion between the Queensland
> Government and OSM as to licence compatibility. See this thread for example:
>
> https://www.mail-archive.com/talk-au@openstreetmap.org/msg10883.html
>
> On Fri, Jan 19, 2018 at 3:34 PM, Satuim <95.5.ra...@gmail.com> wrote:
>
>> Hey everyone,
>>
>> I recently asked for permission to use a CC-BY 4.0 dataset but got
>> rejected. The dataset I want to use is fairly important (boundaries for
>> suburbs and counties for QLD).
>>
>> Here is the response I got:
>>
>> The Department will not provide the data under an Open Database license.
>> It is our belief that a CC:BY licence is sufficient for use of our data.
>>
>>
>> ___
> 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] Help with licensing

[Andrew Davidson]

It's a known problem with a difference of opinion between the Queensland
Government and OSM as to licence compatibility. See this thread for example:

https://www.mail-archive.com/talk-au@openstreetmap.org/msg10883.html

On Fri, Jan 19, 2018 at 3:34 PM, Satuim <95.5.ra...@gmail.com> wrote:

> Hey everyone,
>
> I recently asked for permission to use a CC-BY 4.0 dataset but got
> rejected. The dataset I want to use is fairly important (boundaries for
> suburbs and counties for QLD).
>
> Here is the response I got:
>
> The Department will not provide the data under an Open Database license.
> It is our belief that a CC:BY licence is sufficient for use of our data.
>
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Help with licensing

[Satuim]

Hey everyone,

I recently asked for permission to use a CC-BY 4.0 dataset but got 
rejected. The dataset I want to use is fairly important (boundaries for 
suburbs and counties for QLD).


Here is the response I got:

   The Department will not provide the data under an Open Database
   license. It is our belief that a CC:BY licence is sufficient for use
   of our data.

It is my understanding that the entity does not need to provide/change 
the license, but simply say it is OK for ODbL's slightly different 
terms, Was I misunderstood in my email? what advice can be given here? I 
sent the cover letter/waiver here: 
https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view


I do know of another dataset, but am wondering if I could bounce back 
from this rejection? If not what could I send to help? Is there 
something more persuasive that can be sent, Like anecdotes from local 
members


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

Re: [Talk-transit] Uploading public transport data on OSM

[Andrew Davidson]

On 19/01/18 01:32, Stephen Sprunk wrote:

Agreed; ref:gtfs just won't work, and ref:OPER probably would.



I had always thought that ref was the public facing reference that is 
used (ie: what's on the bus stop sign) and in the GTFS scheme this is 
stop_code. The stop_id is supposed to be unique and is not necessarily 
the same as stop_code. Looking at taginfo the most common way to tag 
stop_id seems to be gtfs_id.


So if there is more than one stop_id for a stop (ie: appears in more 
than one GTFS feed) I would have thought something like:


gtfs_id:OPERATOR=

I have read elsewhere that some mappers prefer to use NETWORK, rather 
than OPERATOR, because their systems get put up for tender for operation 
on a regular basis so NETWORK is more persistent.


I was wondering if there are more than one stop_id is it worthwhile 
tagging something like this:


gtfs_id=A1;B1;C1
gtfs_id:A=A1
gtfs_id:B=B1
gtfs_id:C=C1

So that the data consumers will find multiple values under gtfs_id and 
know to look for an operator or network value. Or is it better to leave 
it blank? I guess it would depend on whether or not you have put 
qualified gtfs_id's on everything or just the shared stops.


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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Paul Norman]

On 1/17/2018 9:14 PM, Oleksiy Muzalyev wrote:


What can I as a map editor do to keep these data files to a reasonable 
size without compromising  data quality? I mean in the sense, - take 
care of the pennies and the pounds will take care of themselves?


I could think of the following three approaches so far:

- using as short an URL as possible, website=http://somewebsite.com 
instead of website=http://www.somewebsite.com , three characters less; 
[2]


- correct phone number ISO format, phone=+12 345 678 90 12 instead of 
phone=+12 (345) 678 90 12 , two characters less;  [3]


- deleting unnecessary nodes from a way (Shift-Y in JOSM) with 
consequent verification of its geometry;


What else, if anything, could be done? 


Speaking as a developer and frequent consumer of OSM data, don't do any 
of these things to save space.


Instead, worry about ease of editing. If a few meter long way has 
hundreds of nodes, that's a problem for editing, and should be fixed; a 
mass of unnecessary import-sourced tags confuses people, don't use them; 
and overlapping landuse with lots of multipolygons is difficult to edit, 
so should be avoided. Following these behaviors will slightly reduce 
data size, but the point is keeping the map maintainable.


It's also difficult to say what will affect size without a detailed 
understanding of the format and how it's processed. Size is also not the 
only indicator of time to process - for various reasons, relations are 
much slower to work with than ways with most data consumption workflows.


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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-18, 16:49 GMT, Jan Martinec wrote:
> No...ulice je tam od 13.století, zatímco hospoda vznikla i zanikla v době,
> k níž ještě existují pamětníci - jmenovala se hospoda podle ulice, nikoli
> naopak (dokonce vedle Jámy byla kavárna Kyvadlo). Velké "J" by tam sice
> mělo být podle nového pravopisu, byť je ulice asi pojmenovaná podle morové
> jámy, která pravděpodobně pojmenování ani neměla, ale s tou jednoznačností
> jména je to hodně vratké ;)

Tak se omlouvám … o jménu blábolím, i když jsem do té hospody 
chodíval na oběd. A pozitivní na tom je, že alespoň vypadá 
stejně dobrá jako bývala před těma skoro dvaceti lety. Úžasné.

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
All parts should go together without forcing. You must remember
that the parts you are reassembling were disassembled by you.
Therefore, if you can't get them together again, there must be a
reason. By all means, do not use a hammer.
-- IBM maintenance manual, 1925


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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-17, 21:14 GMT, Matej Lieskovský wrote:
> @Matěj: Podle ČÚZK žádné díly neexistují a basta! :)

To je další neřešitelná diskuse: je rozhodující ČÚZK nebo cedule 
na plotě?

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
A philosopher like Plato, according to Luther's colorful imagery,
remains like a cow who looks at a new door, refusing to enter?


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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Andrew Hain]

Or a mass change from Name=Untitled Polygon (wasteful but not wrong) to 
name=Untitled Polygon.

--
Andrew

From: Mark Wagner 
Sent: 18 January 2018 19:07:20
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] OSM data, how can we contribute to keep it to a 
reasonable size?

On Thu, 18 Jan 2018 19:44:47 +0100
Oleksiy Muzalyev  wrote:

> Imre,
>
> It is very good and surprising idea.
>
> I discovered on the page "Error categories" a tool
> https://www.keepright.at/ with the help of which I found already
> dozens obviously misspelled tags. It functions quite intuitively,
> just select "misspelled tags" check box and move the map to an area
> of interest.

But make sure they're really misspelled.  I recently saw a change that
fixed a dozen instances where the key "brand" was misspelled as "band"
-- except that one of the "band" tags was correct, describing the fact
that a radio antenna operated in the two-meter band.

--
Mark

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Petr Kadlec]

2018-01-18 21:42 GMT+01:00 Pavel Machek :

> > Budeme se ptát data working group, jestli chtějí v rámci celého světa v
> > názvem používat tečky, velká písmena, mezery, azbuku, … atd.? V českém
>
> Tohle neni ferova argumentace, ze?
>
> Pevne mezery nejsou jen v cestine, takze dava smysl to mit
> konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je
> pekna kravina. Kazdopadne... data working group. Vsude nebo nikde.
>

Pravidlo o jednopísmenných předložkách je jen české. A jako že by se nikde
na světě nezlomitelné mezery vůbec nepoužívaly, to bych taky netvrdil…
Namátkou (i když přiznávám, že jsem čekal větší užití).
https://www.openstreetmap.org/node/2380290743
https://www.openstreetmap.org/relation/1074049
https://www.openstreetmap.org/node/5337546040
https://www.openstreetmap.org/way/454759316 Či dokonce s ještě
zajímavějšími variantami… https://www.openstreetmap.org/node/530880275

Každopádně mi to přijde podobné, jako chtít zakazovat třeba pomlčku; jasně,
není na klávesnici a „-“ může víceméně vcelku fungovat taky a renderer si
to může vyřešit a kdo má vědět, že to mám do Overpass psát takhle atd.

A ano, nástrojům zjevně k ideálu ledacos chybí, ale právě proto je potřeba
vylepšovat nástroje, ne zhoršovat data; jinak bychom dodnes na počítačích
psali bez diakritiky všichni.

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Petr Kadlec]

2018-01-18 20:45 GMT+01:00 Lukáš Karas :

> Overpass to bere s přesností na znak nebo na binární iterpretaci?
> Ptám se protože i pitomá česká diakritika se dá v unicode zapsat různou
> sekvencí bytů... Pokud nějaký software neumí pracovat s unicode, je to
> chyba
> toho softwaru.
>

Ano, a zjevně je to přesně tak, viz seznam omezení na
https://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Accents_and_decorated_characters
(pokud vstup není v NFC, nebude to fungovat; třeba „way["name"="Na
Rybníčku"]“; i když tohle se dá ještě relativně snadno řešit automaticky
na vstupu (dokud se pohybujeme v češtině, kde se nic složitějšího
nevyskytuje)). O složitějších případech nemluvě (jako třeba hledání bez
diakritiky).

V zásadě si Overpass asi představuje, že si to každý ošetří stylem

way["name"~"^V[ \u00A0]Tůních$"]

O implementaci Overpassu nic moc nevím, takže netuším, kolik práce by bylo
to nějak opravit/dodělat.

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Pavel Machek]

On Thu 2018-01-18 14:41:02, Petr Kadlec wrote:
> Ahoj,
> 
> 4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal).
> 
> 2018-01-18 10:46 GMT+01:00 Pavel Machek :
> 
> > ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working
> > group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v
> > nazvech. A podle toho dal. Do te doby...
> >
> 
> Budeme se ptát data working group, jestli chtějí v rámci celého světa v
> názvem používat tečky, velká písmena, mezery, azbuku, … atd.? V českém

Tohle neni ferova argumentace, ze?

Pevne mezery nejsou jen v cestine, takze dava smysl to mit
konzistentni pres cely svet. Osobne si myslim ze mit je v name="" je
pekna kravina. Kazdopadne... data working group. Vsude nebo nikde.
Pavel

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

Re: [OSM-talk-fr] Écluses et portes à flots

[osm . sanspourriel]

Comme on est en milieu essentiellement marin et que les seamark:* sont 
pris de la norme des cartes nautiques électroniques (S57/S63/S100 pour 
les intimes), j'aurais tendance à favoriser :


seamark:gate:category

Et en plus c'est documenté :

https://wiki.openstreetmap.org/wiki/Seamarks/Gates#Categories

Le 18/01/2018 à 16:20, althio - althio.fo...@gmail.com a écrit :

Oui, il faudrait aller chercher l'avis des anglophones natifs.

Pourquoi pas faire la page wiki waterway=tidegate puis notifier sur
tagging, ou l'inverse ;)

De mon côté, pour "floodgate", je ne prendrais pas "flood"
littéralement pour "inondations", mais aussi "montée des eaux",
"débordement", "trop-plein".
Et pour moi on est totalement dans le contrôle d'écoulement (flow
control). Il y a d'autres installations qui sont clairement du "flood
protection".
Je vous laisse vous faire votre opinion, j'ai lu cela :

http://www.wordreference.com/definition/floodgate
[English] floodgate /ˈflʌdˌɡeɪt/ n. Also called: head gate, water gate
1. a gate in a sluice that is used to control the flow of water
2. (often plural: floodgates) a control or barrier against an outpouring or flow
[American] floodgate /ˈflʌdˌgeɪt/   n. [countable] Civil Engineering
1. gate regulating the flow of water.
2. anything serving to control the passage of something

http://www.wordreference.com/synonyms/floodgate
floodgate, sluice gate

http://www.wordreference.com/enfr/floodgate
floodgate n
often plural (gate preventing overflow of water) vanne, porte d'écluse
floodgates npl
figurative (barrier) barrière


En bonus, tout ce que j'ai pu pêcher dans taginfo :

waterway=lock_gate 17 359
waterway=sluice_gate 204
waterway=floodgate 170
waterway=former_lock_gate 12
waterway=gate 5
waterway=stuice_gate 3
waterway=headgate 3
waterway=stuice_gateream 2
waterway=former lock_gate 1
waterway=dock_gate 1
waterway=security_gate 1
waterway=sluicegate 1

waterway=flow_control 261
flow_control=sluice_gate 194
flow_control=water_level 22
flow_control=overflow 12
flow_control=bottom_outlet 11
flow_control=discharge 9
flow_control=entry 3
flow_control=over_flow 2
flow_control=traffic_lights half duplex 1
flow_control=moench 1
flow_control=sluice 1
flow_control=flood_gate 1

gate=flood_wall 6
gate=flood_defence 3
gate=flood_gate 2

seamark:gate:category=lock 295
seamark:gate:category=flood_barrage 51
seamark:gate:category=sluice 29
seamark:gate:category=general 3
seamark:gate:category=dyke 3
seamark:gate:category=caisson 3

2018-01-10 22:17 GMT+01:00  :

oups, j'avais lu flowgate. Comme quoi rien ne sert d'être plus fluent !

Oui, ça correspond protections anti-inondations.

Flood control et non flow control.
flow_control=water_level ? contrôle du niveau de l'eau
waterway=low_weir ? seuil bas

Semblent là aussi surtout utilisé en eaux douces.


Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :

Bonsoir,

ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
en anglais !!!).

Alors que les portes à flots j'ai l'impression que c'est quelque chose de
plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
(zone marécageuses par exemples).



Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :

Ça me plait, ça pourrait être utilisé pour les formes de raboub et les seuil
des ports me semble-t-il.

Pour le moment mes recherches sur Brest et Lorient n'ont rien donné : on a
des eaux ou des formes de raboub mais la séparation se fait par la vertu du
Saint-Esprit.

Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.

Il faudrait presque une info complémentaire car certaines "écluses" sont
faites pour faire entrer l'eau de mer, d'autres pour faire sortie l'eau
douce d'autres pour simplement contrôler le niveau style chasse de la baie
du mont Saint-Michel.


Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
en anglais !!!).

Alors que les portes à flots j'ai l'impression que c'est quelque chose de
plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
(zone marécageuses par exemples).


Le 10/01/2018 à 00:16, althio a écrit :


Par analogie, il faudrait quelque chose comme waterway=tidal_gate

tide gate ou floodgate semble plus courant en anglais.

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


à votre avis on part plutôt sur floodgate parce que cela existe déjà ou sur
un tidegate car plus lié au marée

à plus

Vinber




___
Talk-fr mailing list

Re: [OSM-talk-fr] positionnement des adresses et ménage

[Philippe Verdy]

Je suis d'accord aussi: ce qui va intéresser le moteur de navigation c'est
trouver un chemin d'accès non ambigu (même si pour lever l'ambiguïté il
faut aller au delà du domaine public et entrer sur une voie privée (qui
devra être tracée).

Cependant il reste à associer le nœud portant le numéro à sa rue car si on
passe par une voie privée ou un chemin public sans nom (ou ayant un nom
local non utilisé pour l'adresse tel que "entrée ouest"), la rue indiquée
dans l'adresse ne sera souvent pas la plus proche du nœud (certains
passages par une voie privée d'un tiers sont nécessaires, il y a des cas où
c'est une servitude obligatoire, toute propriété doit avoir un accès libre
à son propriétaire ou ses invités).

Et pour ça on a déjà la relation "associatedStreet" qui évite de copier le
nom de la rue dans tous les nœuds d'adresse (mais cette relation est
discutée, et ne rien mettre dans le nœud et ne pas l'associer non plus dans
une relation produit des erreurs...).

Même si on trace des voies privées, on n'a pas obligation de mettre le nœud
d'adresse dessus, mais il devrait en être assez proche pour qu'il n'y ait
pas d’ambiguïté sur le chemin à suivre (même si ce n'est pas le nom de rue
pour l'adresse indiquée dans le nœud ou la relation "associatedStreet").

Ça résout donc tous les cas et on n'a pas besoin d'attacher non plus ces
nœuds aux bâtiments: on se place sur un nœud à proximité du chemin d'accès
(public ou privé) et plutôt à l'extérieur (sauf en zone urbaine : on se
place à l'intérieur près de la porte d'accès faisant face au trottoir, ou
en limite de propriété s'il y a un jardin ou une cours privée devant, mais
en évitant de se mettre là aussi sur une barrière, un mur de clôture ou un
fossé). Les nœuds d'adresse devraient rester distincts de tout autre objet.

Il reste cependant le cas des POIs (commerces) situés à cheval entre deux
adresses : ces nœuds doivent porter un attribut pour leur propre numéro(s)
pour lever l’ambiguïté de numéro, voire aussi le nom de leur rue (et ils
n'ont pas à figurer en membre de relation "associatedStreet") car ils
peuvent avoir plusieurs accès par des rues différentes.

Si on a une relation 1:1 pour associer ces nœuds POIs aux adresses on peut
réutiliser le même nœud pour les deux (ce qui évite des doublons
d'adresses), sinon il faut les séparer et pour éviter les doublons
d'adresse on pourra toujours metttre le numéro et le nom de rue du POI dans
"contact:*" et non "addr:*".

Le 18 janvier 2018 à 18:52, Cyrille37 OSM  a
écrit :

> Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
>
> Le 16 janvier 2018 à 12:17, jabali  a écrit :Il
> faut accepter qu'une adresse et un bâtiment sont deux notions différentes.
> Dans ton 1er exemple de routage, ce n'est pas le bâtiment qu'il faut viser
> mais son point d'accès soit la barrière (qui devrait porter l'adresse) qui
> matérialise la distinction entre les espaces publics et privés.
>
>
> +1000
>
> immeubles à plusieurs entrées (donc plusieurs numéro), maison très proche
> d'une voie mais dont l'accès se fait par une autre voie. Ce questionnement
> revient régulièrement, et quand on fini par comprendre, c'est bien le point
> d'accès et non le bâti qui porte le numéro d'adresse.
>
> Cyrille37.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Lukáš Karas]

Overpass to bere s přesností na znak nebo na binární iterpretaci? 
Ptám se protože i pitomá česká diakritika se dá v unicode zapsat různou 
sekvencí bytů... Pokud nějaký software neumí pracovat s unicode, je to chyba 
toho softwaru.

Pokud ale v nějakém jazyce nemá být nějaká sekvence znaků samostatně na konci 
řádku, je potřeba za ní dát nedělitelnou mezeru. Protože tohle si žádný 
software z prstu nevycucá. To není psaní názvů pro renderer, to je normální 
psaní textu v unicode.

Lukáš

Dne čtvrtek 18. ledna 2018 18:31:38 CET Matej Lieskovský napsal(a):
> Nominatim tohle zvládá, Overpass (alespoň standardně) nikoliv - ten bere
> nápisy s přesností na znak. Díky tomu jsem na tyhle problémy přišel.
> 
> 2018-01-18 18:26 GMT+01:00 Jan Martinec :
> > N i O mají plnou podporu Unicode, tj. měly by "vidět" všechny mezerovité
> > znaky jako ekvivalentní.
> > 
> > HPM
> > 
> > Dne 18. 1. 2018 18:24 napsal uživatel "Marián Kyral" :
> >> -- Původní e-mail --
> >> Od: Petr Kadlec 
> >> Komu: OpenStreetMap Czech Republic 
> >> Datum: 18. 1. 2018 17:58:17
> >> Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
> >> 
> >> Ahoj,
> >> 
> >> 2018-01-18 17:36 GMT+01:00 jzvc :
> >> 
> >> Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze
> >> typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo
> >> drzet
> >> pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco
> >> tagovat
> >> pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam
> >> vedet, ze v dany lokalite ma ten text spojit.
> >> 
> >> 
> >> Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera,
> >> existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale
> >> nežijeme v platónském světě názvů, my vyrábíme data pro software a tento
> >> software pro reprezentaci textových dat používá Unicode. Proto bychom
> >> měli
> >> vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit
> >> odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z
> >> databáze OSM stáhnu seznam všech ulic, chci to tam mít.
> >> 
> >> 
> >> 
> >> Takže pokud pak budu tu ulici hledat, tak si musím pamatovat, že za "V"
> >> musím napsat nezalomitelnou mezeru, jinak mi třeba nominatin najde velké
> >> kulové? U něj by to ještě šlo nějak ošetřit, ale třeba u Overpass už na
> >> to
> >> musím myslet já. Sám to za mně neudělá. Nekomplikuješ nám to tak trochu?
> >> 
> >> Marián
> >> 
> >> ___
> >> Talk-cz mailing list
> >> Talk-cz@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-cz
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-es] Itinerarios de Semana Santa

[dcapillae]

Creo que nadie ha cuestionado la tradición histórica de la Semana Santa hasta
el momento, Iñaki.

A raíz del comentario de Emilio, lo que he intentado aclarar es que la
práctica de no mapear «elementos históricos» se refiere a elementos del
«pasado histórico», es decir, elementos que ya no existen en el presente
porque se perdieron en el pasado. No es aplicable a los itinerarios de
Semana Santa, pero no porque éstos tengan quinientos o mil años de historia,
sino porque existen en el presente.

Un puente que existió en el pasado pero que ahora no existe, no se puede
mapear. A eso se refiere la práctica de no mapear «elementos históricos». El
puente pudo haber tenido una larga historia detrás, pero si no queda nada de
él sobre el terreno, ni tan siquiera un mínimo resto ruinoso, no se puede
mapear. En OpenStreetMap se pueden mapear elementos históricos, es decir,
con interés históricos, lo que no se puede es mapear elementos del «pasado
histórico», es decir, que existieron en el pasado pero que ya no existen:
https://wiki.openstreetmap.org/wiki/Historic

En cuanto a equiparar la Semana Santa a una marcha ciclista o a una carrera
popular, tampoco creo que nadie haya dicho que sean lo mismo, sino que las
procesiones de Semana Santa pueden entenderse como eventos religiosos o
culturales que se desarrollan a lo largo de un cierto itinerario. Y, en
cuanto a actividad, en cuanto a evento, puede equipararse a otros tipos de
eventos que discurren a lo largo de un itinerario, como las marchas
ciclistas o las carreras populares.

Espero haberme explicado mejor ahora.



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

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

Re: [OSM-talk-fr] schéma des addr

[Ralf Treinen]

Bonsoir,

On Tue, Jan 16, 2018 at 11:43:52PM +, marc marc wrote:

> Donc ma proposition : en cas de nœud-adresse avec une adresse pour un 
> bâtiment, ne pourrait-on pas associer l'adresse au bâtiment soit on 
> mettant le nœud sur le contour ou dans le bâtiment (ou via une relation
> si quelqu'un est motivé pour porter une proposition).

un collegue m'a rappelé il y a quelque temps un très bon principe (si
vous m'excusez l'anglais) :

  simple things should be simple, complicated things should be possible

Une relation (associatedAddress ?) qui associe une adresse à plusieurs
éléments (terrain, des bâtiments, des entrées, des commerces, ...)
me semble assez générale pour couvrir tous les cas que je peux
imaginer. C'est évidement lourd, personne n'a envie de créer
une relation par bâtiment. C'est pourquoi il faut aussi une solution
simple pour la grande majorité des cas qui est : un bâtiment - une
adresse. La solution de Marc de situer dans de tels cas simples l'adresse
au point d'entrée du bâtiment me semble très bien. 

-Ralf.

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[Cyrille37 OSM]

resalut

Je ne suis pas aussi complexe, juste que l'usage d'une adresse me semble 
être de s'y rendre, puis il faut passer de l'espace public à l'espace 
privée, dans lequel la fonction du ou des bâtis ne concernent que les 
habitants/usagers/ Autre exemple (en plus des immeubles) le bâti 
ancien où il y a 2 à 4 bâtis pour la même adresse, ou encore une 
entreprise avec 4 ou 5 bâtis. Encore un autre, en ville cette fois, avec 
les maisons dans les intersections, qui ont l'air bien malines avec leur 
numéro au milieu et 2 voies bordant le coin et deux côtés.


Non franchement, je ne vois pas d'autre point d'accroche "utile" du 
numéro de voie que celui où l'on quitte l'espace public pour passer dans 
l'espace "privé" ou "d'usage".


Cyrille37.

Le 18/01/2018 à 19:39, marc marc a écrit :

Le 18. 01. 18 à 18:52, Cyrille37 OSM a écrit :

Le 17/01/2018 à 21:57, Romain MEHUT a écrit :

Le 16 janvier 2018 à 12:17, jabali a écrit :Il faut accepter qu'une
adresse et un bâtiment sont deux notions différentes. Dans ton 1er
exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son
point d'accès soit la barrière (qui devrait porter l'adresse) qui
matérialise la distinction entre les espaces publics et privés.

maison très proche d'une voie mais dont l'accès se fait par une autre voie.

j'aimerais bien voir un cas réel d'adresse de la rue A situé le long de
la rue B... j'imagine que ce genre de nœud doit parfois faire des yoyo.
On peux tout aussi bien résoudre le problème de routing en traçant le
chemin d'accès réel jusqu'à la maison. Ce n'est donc pas un bon argument
(si on veux un objet = une fonction, alors la position de l'adresse ne
sert pas au routing, c'est le rôle des routes de servir à cela).


c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.

Si on veux être puriste, je pense que c'est la parcelle qui porte
souvent l'adresse. Avant même qu'un architecte ai dessiné la voie
d'accès, la rue a parfois été saucissonnée pour attribuer les numéros
"non utilisé" aux parcelles non bâties.
Pour couper court, je ne nie pas qu'une adresse et un bâtiment sont 2
choses différentes. je reproche juste le manque de lien indispensable
entre les 2.
C'est bien (ou pas) de tager pour le routing.
Mais c'est tout aussi bien d'avoir la possibilité de se repérer sur une
carte (cela fait partie de la fonction première) et donc savoir quel est
l'adresse d'un bâtiment donné, le savoir avec certitude, pas en mode
devinette ou procéder par élimination/supposition dans les situations un
peu plus "tordue" qu'un alignement de maison le long d'une rue.
je t'invite à lire mon argumentation dans le sujet "schéma des adresses".
J'y expose un outil (qui n'est pas de moi) qui montre quand il y a un
lien entre un nœud adresse et le bâtiment... et quand il n'y en a pas.
je t'invite à faire une proposition pour combler ce manque.
Cela permettrait ensuite de demander aux applications de supporter ce
lien et donc d'afficher l'adresse du bâtiment quand on le sélectionne et
d'éviter ainsi que les utilisateur encode des doublons lorsque le nœud
se situe hors du bâtiment qui la concerne.
Parce que pour le moment, aucune application ne donne l'adresse d'un
bâtiment qui a un nœud adresse à x mètres. Nominatim se contente de
déplacer ta demande au nœud le plus proche... qui est juste... ou pas.
___
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] OSM data, how can we contribute to keep it to a reasonable size?

[Oleksiy Muzalyev]

On 18.01.2018 20:07, Mark Wagner wrote:

On Thu, 18 Jan 2018 19:44:47 +0100
Oleksiy Muzalyev  wrote:


Imre,

It is very good and surprising idea.

I discovered on the page "Error categories" a tool
https://www.keepright.at/ with the help of which I found already
dozens obviously misspelled tags. It functions quite intuitively,
just select "misspelled tags" check box and move the map to an area
of interest.

But make sure they're really misspelled.  I recently saw a change that
fixed a dozen instances where the key "brand" was misspelled as "band"
-- except that one of the "band" tags was correct, describing the fact
that a radio antenna operated in the two-meter band.

Indeed, I see already that there could be from time to time 
false-positives. It makes sense to open a node in a separate browser tab 
and to check a tag info at the OSM wiki before correction.



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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Mark Wagner]

On Thu, 18 Jan 2018 19:44:47 +0100
Oleksiy Muzalyev  wrote:

> Imre,
> 
> It is very good and surprising idea.
> 
> I discovered on the page "Error categories" a tool 
> https://www.keepright.at/ with the help of which I found already
> dozens obviously misspelled tags. It functions quite intuitively,
> just select "misspelled tags" check box and move the map to an area
> of interest.

But make sure they're really misspelled.  I recently saw a change that
fixed a dozen instances where the key "brand" was misspelled as "band"
-- except that one of the "band" tags was correct, describing the fact
that a radio antenna operated in the two-meter band.

-- 
Mark

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

Re: [Talk-es] Itinerarios de Semana Santa

[Iñaki]

Buenas tardes:

Muy curioso lo de la Semana Santa y su mapeo. Evidentemente no entro en 
el aspecto técnico de si hay que mapear o no, pero hay dos conceptos que 
me han llamado poderosamente la atención y que entiendo merecen una 
reflexión.


Nos guste o no, la Semana Santa es Historia, es un “elemento histórico”. 
Un hecho que se remonta hasta la más oscura antigüedad de nuestra 
historia, estos es, es Historia (con mayúscula). Y lo que ya es un serio 
riesgo de perder el norte es situar a la misma altura las “carreras 
populares”, “marchas ciclistas” y los eventos de Semana Santa. Y, por 
supuesto, que hay carreras populares, por ejemplo, que comienzan a 
aparecer en los estudios locales de Historia.


En la carrera de Historia, hay (o había) una asignatura centrada en las 
tendencias historiográficas. Así sin más, no dice gran cosa; ahora bien, 
resulta (resultaba) ser una de las más enriquecedoras para los futuros 
historiadores. No se puede definir qué es o no cultura y, 
consecuentemente, qué es y no Historia. La asignatura era una ducha de 
modestia. Y al cuestionar la Semana Santa como algo que pudiera estar al 
margen de la Historia, me ha sorprendido.


Reflexionemos sobre ello.

Saludos,

Iñaki


El 18/01/2018 a las 13:06, dcapillae escribió:

Gracias, Emilio.

Creo que la práctica de no cartografiar elementos históricos se refiere a
elementos del «pasado histórico». En el caso de los itinerarios de Semana
Santa no estaríamos ante un elemento histórico, sino ante un evento
religioso o cultural del presente y que ocurre todos los años.

Ahora bien, quizás hayas tocado una de las claves para no incluir estos
itinerarios en la base de datos de OSM, el considerar estos itinerarios no
como recorridos predeterminados ni de interés público sino como eventos
culturales. En tal caso, como justificación para no mapear los itinerarios
de Semana Santa podría valernos la primera parte de tu argumento: no mapear
carreras populares, marchas ciclistas ni eventos similares.



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

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



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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Oleksiy Muzalyev]

Imre,

It is very good and surprising idea.

I discovered on the page "Error categories" a tool 
https://www.keepright.at/ with the help of which I found already dozens 
obviously misspelled tags. It functions quite intuitively, just select 
"misspelled tags" check box and move the map to an area of interest.


Best regards,
Oleksiy

On 18.01.2018 15:48, Imre Samu wrote:
>What can I as a map editor do to keep these data files to a 
reasonable size without compromising  data quality?


According to the "Lean thinking" ( 
https://en.wikipedia.org/wiki/Lean_thinking ) we should focus on 
" eliminating waste"

Waste is:
*  Any polygon or  tagging errors ( because we can't use this 
information, and need lot of space or processing resources )  or any 
from this: https://wiki.openstreetmap.org/wiki/Error_categories ;  etc
*  or any mapping errors ( bad street names ;  routing problems: waste 
for users   )
*  or any not "UpToDate" data/information  ( old phone numbers -   it 
is useless,  so it is waste )


some examples:
http://area.jochentopf.com/stats/
- Errors: Intersections
- Errors: Duplicate nodes
- Errors: Duplicate segments (*~160.000*)
- Errors: Open rings  ( ~9.000)
- Errors: Inner rings with same tags as outer rings
- Errors: Wrong role ( *~ 700.000 *)

some key problems:  ( unused/bad keys is a waste )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#problem 
( Keys with possibly problematic characters )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#space 
 ( Keys with whitespace )

- or my favorite:
--- https://taginfo.openstreetmap.org/keys/latitude#values
--- https://taginfo.openstreetmap.org/keys/LAT#values

And we have lot of low quality imports we should fix.

>What can I as a map editor

imho:
Any quality assurance work helps a lot: 
https://wiki.openstreetmap.org/wiki/Quality_assurance
so fixing data problems in your area helps "eliminating waste"    and  
less waste is good for data size



Imre



2018-01-18 6:14 GMT+01:00 Oleksiy Muzalyev 
>:


Good morning,

I started to experiment with the OSM data [1] on a local computer,
and I begin to realize how big these data files are. It takes
quite a while to load into the local database just the data for
one country.

What can I as a map editor do to keep these data files to a
reasonable size without compromising  data quality? I mean in the
sense, - take care of the pennies and the pounds will take care of
themselves?

I could think of the following three approaches so far:

- using as short an URL as possible,
website=http://somewebsite.com instead of
website=http://www.somewebsite.com  ,
three characters less; [2]

- correct phone number ISO format, phone=+12 345 678 90 12 instead
of phone=+12 (345) 678 90 12 , two characters less; [3]

- deleting unnecessary nodes from a way (Shift-Y in JOSM) with
consequent verification of its geometry;

What else, if anything, could be done?

[1] https://wiki.openstreetmap.org/wiki/Downloading_data

[2] https://wiki.openstreetmap.org/wiki/Key:website

[3] https://wiki.openstreetmap.org/wiki/Key:phone


With best regards,
Oleksiy
osm: Alex-7

___
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: [OSRM-talk] calculation of jump distances

[Sayer, Bryan]

Thanks! I was wondering if some of these might be islands. I haven’t had time 
to check out the details of ones with extra large jump distances yet, but I’ll 
try to do that in the next few days.

Bryan Sayer
(301) 628-1576

From: Daniel Patterson [mailto:dan...@mapbox.com]
Sent: Thursday, January 18, 2018 12:25 PM
To: Sayer, Bryan 
Cc: Mailing list to discuss Project OSRM 
Subject: Re: [OSRM-talk] calculation of jump distances

Hi Bryan,

  OSRM uses an R-Tree (https://en.wikipedia.org/wiki/R-tree) to do a nearest 
neighbour search (https://en.wikipedia.org/wiki/Nearest_neighbor_search).  
Every segment (line between two OSM nodes) is indexed in the R-Tree, and we 
snap to the closest straight line, measured with the Haversine distance method.

  One thing that might be coming into play is OSRM's "small component" snapping 
behaviour - how OSRM behaves when your start and end point are not actually 
connected (e.g. one point on an island, one on the mainland).

  There's an older blog post here:


https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8

  that describes this behaviour.  It's possible this is coming into play for 
some locations, but you'd need to look very closely at your data and the 
failing requests to really understand what's going on.

daniel

On Wed, Jan 17, 2018 at 7:10 AM, Sayer, Bryan 
> wrote:
Hi Daniel,

Thanks for the advice. We use the Stata implementation on a secure network so I 
can’t try any of the usual options that are available over the internet. I will 
double check that I have the order (longitude, latitude) but I have over 450 
million routes all over the USA (every populated tract to every hospital, with 
certain restrictions in Hawaii and Alaska), so I imagine if I had them reversed 
I would have really strange results.

I can check the area size of the tracts. I suppose some tracts might not have 
any roads, but generally tracts are defined by roads or natural elements like 
rivers. I only use tracts with non-zero population, so it seems like every 
tract I use should have a road in it. It seems to me that it should never be 
the case that the jump distance from the tract centroid to the starting point 
should exceed the largest dimension of the tract, or really one-half of that 
distance.

It is not a large number of routes with these large jump distances, just a few.

When you say “the first thing that happens is that the nearest point on the 
road network is found” how is the nearest road network found? That is, what is 
the algorithm? Does it spiral out from the point until a road is hit?


Bryan Sayer
Statistician
Social & Scientific Systems, Inc.
Monday-Friday 9:30 to 5:30
(301) 628-1576
https://www.s-3.com/


From: Daniel Patterson [mailto:dan...@mapbox.com]
Sent: Tuesday, January 16, 2018 5:24 PM
To: Mailing list to discuss Project OSRM 
>
Subject: Re: [OSRM-talk] calculation of jump distances

Hi Bryan,

  OSRM stores the road network in memory.  When you supply a coordinate to 
start/finish a route, the first thing that happens is that the nearest point on 
the road network is found.  Routing then happens from those "snapped" points.

  If you've got big rural areas, and you're using large regional centroids, 
then I suspect the snapping is starting or finishing your routes on roads you 
don't expect.

  Several hundred KM is pretty weird though, unless your road network is 
*really* sparse.  Do you have your coordinate the correct way around in your 
requests?  The order should be , for every pair - getting 
this wrong is often the source of really weird results.

  Try making a single request with `overview=full=geojson`, then 
plot the full route geometry on http://geojson.io/ or something to see if it 
even looks reasonable.

daniel

On Tue, Jan 16, 2018 at 1:43 PM, Sayer, Bryan 
> wrote:

Hi,



We are calculating distances between an U.S. census tract centroid and 
hospitals. A tract averages about 4,000 people, but can vary in area. 
Obviously, the centroid is likely to not be on a street, and thus a jump 
distance has to be calculated to get to a street.



Our question is what is the general algorithm for getting to the starting 
point? We definitely end up with some very large numbers (several hundred 
kilometers) on some jump distances, which seems incorrect.



Bryan Sayer

WARNING This information may be confidential. It is intended only for 
the addressee(s) identified above. If you are not the addressee(s), or an 
employee or agent of the addressee(s), please note that any dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have received this information in error, please destroy the information and 
notify the sender of 

Re: [OSM-talk-fr] positionnement des adresses et ménage

[marc marc]

Le 18. 01. 18 à 18:52, Cyrille37 OSM a écrit :
> Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
>> Le 16 janvier 2018 à 12:17, jabali a écrit :Il faut accepter qu'une 
>> adresse et un bâtiment sont deux notions différentes. Dans ton 1er 
>> exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son 
>> point d'accès soit la barrière (qui devrait porter l'adresse) qui 
>> matérialise la distinction entre les espaces publics et privés.

> maison très proche d'une voie mais dont l'accès se fait par une autre voie. 

j'aimerais bien voir un cas réel d'adresse de la rue A situé le long de 
la rue B... j'imagine que ce genre de nœud doit parfois faire des yoyo.
On peux tout aussi bien résoudre le problème de routing en traçant le 
chemin d'accès réel jusqu'à la maison. Ce n'est donc pas un bon argument 
(si on veux un objet = une fonction, alors la position de l'adresse ne 
sert pas au routing, c'est le rôle des routes de servir à cela).

> c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.

Si on veux être puriste, je pense que c'est la parcelle qui porte 
souvent l'adresse. Avant même qu'un architecte ai dessiné la voie 
d'accès, la rue a parfois été saucissonnée pour attribuer les numéros 
"non utilisé" aux parcelles non bâties.
Pour couper court, je ne nie pas qu'une adresse et un bâtiment sont 2 
choses différentes. je reproche juste le manque de lien indispensable 
entre les 2.
C'est bien (ou pas) de tager pour le routing.
Mais c'est tout aussi bien d'avoir la possibilité de se repérer sur une 
carte (cela fait partie de la fonction première) et donc savoir quel est 
l'adresse d'un bâtiment donné, le savoir avec certitude, pas en mode 
devinette ou procéder par élimination/supposition dans les situations un 
peu plus "tordue" qu'un alignement de maison le long d'une rue.
je t'invite à lire mon argumentation dans le sujet "schéma des adresses".
J'y expose un outil (qui n'est pas de moi) qui montre quand il y a un 
lien entre un nœud adresse et le bâtiment... et quand il n'y en a pas.
je t'invite à faire une proposition pour combler ce manque.
Cela permettrait ensuite de demander aux applications de supporter ce 
lien et donc d'afficher l'adresse du bâtiment quand on le sélectionne et 
d'éviter ainsi que les utilisateur encode des doublons lorsque le nœud 
se situe hors du bâtiment qui la concerne.
Parce que pour le moment, aucune application ne donne l'adresse d'un 
bâtiment qui a un nœud adresse à x mètres. Nominatim se contente de 
déplacer ta demande au nœud le plus proche... qui est juste... ou pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Videa z OpenAlt

[Pavel Zbytovský]

Ahoj,

všechny záznamy i slidy z českého SotMu jsem vyzobnul na
https://openstreetmap.cz/sotm a též tweetnul [1].
Doporučuju shlédnout, je to fakt zajímavé. :)

Pavel


[1]:
https://twitter.com/osmcz/status/954054466323574784
https://www.facebook.com/osmcz/posts/889616337875881



On Fri, Dec 15, 2017 at 8:50 AM Tom Ka  wrote:

> Ahoj,
>
> prvni verze videi (zatim bez slajdu) v OpenAlt / SotM CZ 2017 je k
> dispozici online:
>
> Sobota:
>
> https://www.superlectures.com/openalt2017/udalo-se-ve-svete-openstreetmap
>
> Nedele:
> https://www.superlectures.com/openalt2017/nedele-5-11-2017-a112
>
> A urcite najdete i prednasky mimo OSM, ktere stoji za to :-)
>
> Enjoy!
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Atelier de lutherie

[Rodrigo Vivar]

Bonjour

Vois pas pourquoi mettre métier dans description, pourquoi ajouter niveau intermédiaire "strings ou wind", apporte quoi ?

serais plutôt d'accord avec marc marc pour "musical_instrument=luthier". m'étonnerais chercher les fabricants d'instrument à corde, mais chercher "luthier" ou autre artisan oui.

Et lutherie connue en plusieurs langues

 

Quand décision pris, comment vous faites ici pour wiki : modifiez ou voyez avec autres pays ?

Et pour les quelques tags dans osm qui sont plus bon vous modifiez ?

 

cordialmnt

Rod 

 


2. Re: Atelier de lutherie (Julien Coupey)
3. Re: Atelier de lutherie (osm.sanspourr...@spamgourmet.com)



From: Julien Coupey 

Bonsoir,

Merci pour vos réponses. Je suis parti sur la combinaison :

shop=musical_instrument
craft=musical_instrument
musical_instrument=strings (ou wind)

La seule chose qui n'est pas vraiment décrite est le fait de fabriquer
en plus de faire de la réparation (le cas des luthiers des instruments
du quatuor). J'ai précisé ça avec le tag description qui est finalement
le seul où apparaît le mot luthier le cas échéant.

À+
Julien

Le 15/01/2018 à 09:53, Thibaud B a écrit :
> Bonjour,
>
>
> Je suis d'accord avec l'utilisation de craft=musical_instrument +
> musical_instrument=* et/ou éventuellement un tag description=* pour
> préciser l'activité de l'artisan, car ils peuvent parfois
> réparer/fabriquer plusieurs type d'instruments.
>
> Voir exemple ici : https://www.openstreetmap.org/node/5025952922
>
> Ici l'artisan répare tout type d'instrument à vent, j'ai préférer le
> mettre dans description , mais pourquoi pas un musical_instrument=wind
>
> Cordialement,
>
> 
> *De :* marc marc 
> *Envoyé :* dimanche 14 janvier 2018 01:10
> *À :* talk-fr@openstreetmap.org
> *Objet :* Re: [OSM-talk-fr] Atelier de lutherie
> Bonjour,
>
> Le 13. 01. 18 à 22:48, Julien Coupey a écrit :
>> C'est shop=musical_instrument[2] qui semble s'approcher le plus sur le
>> wiki, mais sans évoquer l'aspect de création artisanale.
>> Taginfo trouve seulement 22 occurences de craft=luthier, est-ce que vous
>> conseilleriez de l'utiliser ? D'autres idées ?
>
> si shop=musical_instrument semble une bonne idée,
> par analogie, tu peux mettre craft=musical_instrument 36 occurrences
> https://taginfo.openstreetmap.org/tags/?key=craft=musical_instrument
>
> Si la précision que c'est un luthier te semble nécessaire,
> pour ma part je privilégiais un sous-tag genre
> craft=musical_instrument + musical_instrument=luthier
>
> Cordialement,
> Marc
--

Message: 3
Date: Tue, 16 Jan 2018 23:44:25 +0100
From: osm.sanspourr...@spamgourmet.com
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Atelier de lutherie
Message-ID: <790412be-9eff-6367-d386-95874862c...@gmx.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Si, la clé craft indique que c'est de la fabrication :

https://wiki.openstreetmap.org/wiki/Key:craft

A minima de l'artisanat.
Tu peux éventuellement ajouter qu'elle fait aussi de la réparation :
https://wiki.openstreetmap.org/wiki/Key:repair

Le 16/01/2018 à 21:11, Julien Coupey - o...@coupey.fr a écrit :
> Bonsoir,
>
> Merci pour vos réponses. Je suis parti sur la combinaison :
>
> shop=musical_instrument
> craft=musical_instrument
> musical_instrument=strings (ou wind)
>
> La seule chose qui n'est pas vraiment décrite est le fait de fabriquer
> en plus de faire de la réparation (le cas des luthiers des instruments
> du quatuor). J'ai précisé ça avec le tag description qui est
> finalement le seul où apparaît le mot luthier le cas échéant.
>
> À+
> Julien

 



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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[Cyrille37 OSM]

Le 17/01/2018 à 21:57, Romain MEHUT a écrit :
Le 16 janvier 2018 à 12:17, jabali > a écrit :Il faut accepter qu'une 
adresse et un bâtiment sont deux notions différentes. Dans ton 1er 
exemple de routage, ce n'est pas le bâtiment qu'il faut viser mais son 
point d'accès soit la barrière (qui devrait porter l'adresse) qui 
matérialise la distinction entre les espaces publics et privés.


+1000

immeubles à plusieurs entrées (donc plusieurs numéro), maison très 
proche d'une voie mais dont l'accès se fait par une autre voie. Ce 
questionnement revient régulièrement, et quand on fini par comprendre, 
c'est bien le point d'accès et non le bâti qui porte le numéro d'adresse.


Cyrille37.

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

Re: [OSRM-talk] Any Insight on OSRM re: Valhalla team?

[Jason Dalton]

Thanks Daniel,

We'll definitely be watching the developments, and thanks for weighing in
on it.  For what it's worth, we really like OSRM's method of easily
configuring and switching modes of travel with lua files.  That feature is
very important to us and I hope it stays in the combined effort in some
fashion.
Thanks,
Jason

On Tue, Jan 16, 2018 at 5:19 PM, Daniel Patterson  wrote:

> Hi Jason,
>
>   Good question!
>
>   The short term is - not much will change.  The team is working on
> migrating the hosted Valhalla services over to Mapbox's infrastructure (so
> Mapzen customers have somewhere to turn when valhalla.mapzen.com goes
> away).  That'll take the next few weeks.
>
>   Planning will come after that - each project has strengths and
> weaknesses, and we don't quite know yet how it's going to play out.  We do
> want to share logic where it makes sense (e.g. turn-by-turn instruction
> generation heuristics, non point in doing that two different ways), but
> exactly what comes out the other end remains to be seen.
>
>   Stay tuned and track tickets in both repos though, we're all pretty
> excited about the possibilities :-)
>
> daniel
>
>
>
> On Tue, Jan 16, 2018 at 1:48 PM, Jason Dalton 
> wrote:
>
>> Now that the Valhalla team is being brought in at MapBox, are there plans
>> to merge Valhalla and OSRM roadmaps? Will one project be the main focus of
>> routing work?
>>
>> --
>> *Jason Dalton*
>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>


-- 
*Jason Dalton*
President, CEO
Azimuth1, LLC
www.azimuth1.com
www.smartdata-solutions.com
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matej Lieskovský]

Nominatim tohle zvládá, Overpass (alespoň standardně) nikoliv - ten bere
nápisy s přesností na znak. Díky tomu jsem na tyhle problémy přišel.

2018-01-18 18:26 GMT+01:00 Jan Martinec :

> N i O mají plnou podporu Unicode, tj. měly by "vidět" všechny mezerovité
> znaky jako ekvivalentní.
>
> HPM
>
> Dne 18. 1. 2018 18:24 napsal uživatel "Marián Kyral" :
>
>>
>> -- Původní e-mail --
>> Od: Petr Kadlec 
>> Komu: OpenStreetMap Czech Republic 
>> Datum: 18. 1. 2018 17:58:17
>> Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
>>
>> Ahoj,
>>
>> 2018-01-18 17:36 GMT+01:00 jzvc :
>>
>> Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze
>> typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet
>> pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat
>> pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam
>> vedet, ze v dany lokalite ma ten text spojit.
>>
>>
>> Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera,
>> existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale
>> nežijeme v platónském světě názvů, my vyrábíme data pro software a tento
>> software pro reprezentaci textových dat používá Unicode. Proto bychom měli
>> vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit
>> odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z
>> databáze OSM stáhnu seznam všech ulic, chci to tam mít.
>>
>>
>>
>> Takže pokud pak budu tu ulici hledat, tak si musím pamatovat, že za "V"
>> musím napsat nezalomitelnou mezeru, jinak mi třeba nominatin najde velké
>> kulové? U něj by to ještě šlo nějak ošetřit, ale třeba u Overpass už na to
>> musím myslet já. Sám to za mně neudělá. Nekomplikuješ nám to tak trochu?
>>
>> Marián
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Martinec]

N i O mají plnou podporu Unicode, tj. měly by "vidět" všechny mezerovité
znaky jako ekvivalentní.

HPM

Dne 18. 1. 2018 18:24 napsal uživatel "Marián Kyral" :

>
> -- Původní e-mail --
> Od: Petr Kadlec 
> Komu: OpenStreetMap Czech Republic 
> Datum: 18. 1. 2018 17:58:17
> Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
>
> Ahoj,
>
> 2018-01-18 17:36 GMT+01:00 jzvc :
>
> Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze
> typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet
> pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat
> pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam
> vedet, ze v dany lokalite ma ten text spojit.
>
>
> Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera,
> existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale
> nežijeme v platónském světě názvů, my vyrábíme data pro software a tento
> software pro reprezentaci textových dat používá Unicode. Proto bychom měli
> vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit
> odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z
> databáze OSM stáhnu seznam všech ulic, chci to tam mít.
>
>
>
> Takže pokud pak budu tu ulici hledat, tak si musím pamatovat, že za "V"
> musím napsat nezalomitelnou mezeru, jinak mi třeba nominatin najde velké
> kulové? U něj by to ještě šlo nějak ošetřit, ale třeba u Overpass už na to
> musím myslet já. Sám to za mně neudělá. Nekomplikuješ nám to tak trochu?
>
> Marián
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Marián Kyral]

-- Původní e-mail --
Od: Petr Kadlec 
Komu: OpenStreetMap Czech Republic 
Datum: 18. 1. 2018 17:58:17
Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
"
Ahoj,




2018-01-18 17:36 GMT+01:00 jzvc :
"Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze
typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet
pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat
pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam 
vedet, ze v dany lokalite ma ten text spojit.
"



Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera, existuje
název, v němž se nesmí na nějakém místě zalomit řádek. My ale nežijeme v
platónském světě názvů, my vyrábíme data pro software a tento software pro
reprezentaci textových dat používá Unicode. Proto bychom měli vzít název a
podle toho, jak se má správně psát,[1] bychom měli zvolit odpovídající
reprezentaci v Unicode. Nejde jen o renderer. Když si z databáze OSM stáhnu
seznam všech ulic, chci to tam mít.


 




"


Takže pokud pak budu tu ulici hledat, tak si musím pamatovat, že za "V"
musím napsat nezalomitelnou mezeru, jinak mi třeba nominatin najde velké
kulové? U něj by to ještě šlo nějak ošetřit, ale třeba u Overpass už na to
musím myslet já. Sám to za mně neudělá. Nekomplikuješ nám to tak trochu?

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Petr Kadlec]

Ahoj,

2018-01-18 17:36 GMT+01:00 jzvc :

> Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze
> typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo drzet
> pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco tagovat
> pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel reneder sam
> vedet, ze v dany lokalite ma ten text spojit.
>

Ano, v platónském světě názvů ulic neexistuje nezalomitelná mezera,
existuje název, v němž se nesmí na nějakém místě zalomit řádek. My ale
nežijeme v platónském světě názvů, my vyrábíme data pro software a tento
software pro reprezentaci textových dat používá Unicode. Proto bychom měli
vzít název a podle toho, jak se má správně psát,[1] bychom měli zvolit
odpovídající reprezentaci v Unicode. Nejde jen o renderer. Když si z
databáze OSM stáhnu seznam všech ulic, chci to tam mít.


> Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy
> nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu.
>

E? Kde v OSM se v jakém kontextu [ne]vyskytuje jaký znak pro měnu a co s
tím má společného renderer? Jako že když existuje podnik „Vše za $0,99“,
tak tam mám psát „Vše za USD0,99“ a je věcí rendereru, aby to vykreslil
správně, nebo jakožecože?


> -- Petr Kadlec / Mormegil
>
>
> A mimochodem, v textu se pise pomlcka – (pripadne — pokud pises basne) a
> ne minus -.
>

„-“ není minus o nic víc než pomlčka (minus je „−“). A „--“ není a nemá být
pomlčka.

-- Petr Kadlec / Mormegil

[1]: http://prirucka.ujc.cas.cz/?id=880
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Martinec]

No...ulice je tam od 13.století, zatímco hospoda vznikla i zanikla v době,
k níž ještě existují pamětníci - jmenovala se hospoda podle ulice, nikoli
naopak (dokonce vedle Jámy byla kavárna Kyvadlo). Velké "J" by tam sice
mělo být podle nového pravopisu, byť je ulice asi pojmenovaná podle morové
jámy, která pravděpodobně pojmenování ani neměla, ale s tou jednoznačností
jména je to hodně vratké ;)

Zdar,
HPM

Dne 18. 1. 2018 16:02 napsal uživatel "Matěj Cepl" :

On 2018-01-18, 13:30 GMT, Marián Kyral wrote:
> Tam je problém, pravidla pravopisu se občas mění a záleží jak
> se k tomu postaví místní samospráva (ta co pojmenovává ulice).

Point nebylo velké nebo malé písmeno (a tady je zcela nepochybně
velké, protože se jedná o bývalou hospodu Jáma,
https://www.openstreetmap.org/way/4387743), ale jednopísmenová
předložka, která si zaslouží oddělit od druhého slova
nezlomitelnou mezerou, což je co jsem v tom textu měl.

Matěj
--
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Do not long for the night, when people vanish in their place.
Be careful, do not turn to evil; for you have preferred this to
affliction.
  -- Job 36:20f (NASB)


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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[jzvc]

Dne 18.1.2018 v 14:41 Petr Kadlec napsal(a):

Ahoj,

4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal).

2018-01-18 10:46 GMT+01:00 Pavel Machek >:

...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working
group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v
nazvech. A podle toho dal. Do te doby...


Budeme se ptát data working group, jestli chtějí v rámci celého světa v
názvem používat tečky, velká písmena, mezery, azbuku, … atd.? V českém
textu se prostě např. po jednopísmenných předložkách píše nezlomitelná
mezera.


Ne, nepise, nic jako nezalomitelna mezera neexistuje. To je pouze 
typograficka pomucka pro SW, ktery neumi jinak rict, ze by neco melo 
drzet pri sobe. Ve skutecnosti je to exaktne totez, jako kdyz budes neco 
tagovat pro reneder, coz se v OSM vyslovene zapovida. Spravne by mel 
reneder sam vedet, ze v dany lokalite ma ten text spojit.


Ale tahle debata už tu proběhla.


Římské číslice v Unicode jsou úplně jiná situace a do názvů nepatří. Viz
Unicode Standard 10.0.0, kapitola 22.3 (s. 798) [1]; TLDR existují jen
kvůli východoasijským zemím: „For most purposes, it is preferable to
compose the Roman numerals from sequences of the appropriate Latin
letters. However, the uppercase and lowercase variants of the Roman
numerals through 12, plus L, C, D, and M, have been encoded in the
Number Forms block (U+2150..U+218F) for compatibility with East Asian
standards. Unlike sequences of Latin letters, these symbols remain
upright in vertical layout. Additionally, in certain locales, compact
date formats use Roman numerals for the month, but may expect the use of
a single character.“


Ve skutecnosti ma trebas dolar znak pro svoji menu, ale v OSM by nikdy 
nikde byt nemel, tam by mel byt kod meny. Opet je to vec renederu. Na 
druhou stranu existuji znaky, trebas (c), coz ve skutecnosti je jeden 
znak, a tudiz by to i jako jeden znak melo byt pouzivano.






-- Petr Kadlec / Mormegil


A mimochodem, v textu se pise pomlcka – (pripadne — pokud pises basne) a 
ne minus -.




[1]: https://www.unicode.org/versions/Unicode10.0.0/ch22.pdf


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




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

Re: [OSM-talk-fr] Écluses et portes à flots

[althio]

Oui, il faudrait aller chercher l'avis des anglophones natifs.

Pourquoi pas faire la page wiki waterway=tidegate puis notifier sur
tagging, ou l'inverse ;)

De mon côté, pour "floodgate", je ne prendrais pas "flood"
littéralement pour "inondations", mais aussi "montée des eaux",
"débordement", "trop-plein".
Et pour moi on est totalement dans le contrôle d'écoulement (flow
control). Il y a d'autres installations qui sont clairement du "flood
protection".
Je vous laisse vous faire votre opinion, j'ai lu cela :

http://www.wordreference.com/definition/floodgate
[English] floodgate /ˈflʌdˌɡeɪt/ n. Also called: head gate, water gate
1. a gate in a sluice that is used to control the flow of water
2. (often plural: floodgates) a control or barrier against an outpouring or flow
[American] floodgate /ˈflʌdˌgeɪt/   n. [countable] Civil Engineering
1. gate regulating the flow of water.
2. anything serving to control the passage of something

http://www.wordreference.com/synonyms/floodgate
floodgate, sluice gate

http://www.wordreference.com/enfr/floodgate
floodgate n
often plural (gate preventing overflow of water) vanne, porte d'écluse
floodgates npl
figurative (barrier) barrière


En bonus, tout ce que j'ai pu pêcher dans taginfo :

waterway=lock_gate 17 359
waterway=sluice_gate 204
waterway=floodgate 170
waterway=former_lock_gate 12
waterway=gate 5
waterway=stuice_gate 3
waterway=headgate 3
waterway=stuice_gateream 2
waterway=former lock_gate 1
waterway=dock_gate 1
waterway=security_gate 1
waterway=sluicegate 1

waterway=flow_control 261
flow_control=sluice_gate 194
flow_control=water_level 22
flow_control=overflow 12
flow_control=bottom_outlet 11
flow_control=discharge 9
flow_control=entry 3
flow_control=over_flow 2
flow_control=traffic_lights half duplex 1
flow_control=moench 1
flow_control=sluice 1
flow_control=flood_gate 1

gate=flood_wall 6
gate=flood_defence 3
gate=flood_gate 2

seamark:gate:category=lock 295
seamark:gate:category=flood_barrage 51
seamark:gate:category=sluice 29
seamark:gate:category=general 3
seamark:gate:category=dyke 3
seamark:gate:category=caisson 3

2018-01-10 22:17 GMT+01:00  :
> oups, j'avais lu flowgate. Comme quoi rien ne sert d'être plus fluent !
>
> Oui, ça correspond protections anti-inondations.
>
> Flood control et non flow control.
> flow_control=water_level ? contrôle du niveau de l'eau
> waterway=low_weir ? seuil bas
>
> Semblent là aussi surtout utilisé en eaux douces.
>
>
> Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :
>
> Bonsoir,
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
>
> Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :
>
> Ça me plait, ça pourrait être utilisé pour les formes de raboub et les seuil
> des ports me semble-t-il.
>
> Pour le moment mes recherches sur Brest et Lorient n'ont rien donné : on a
> des eaux ou des formes de raboub mais la séparation se fait par la vertu du
> Saint-Esprit.
>
> Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.
>
> Il faudrait presque une info complémentaire car certaines "écluses" sont
> faites pour faire entrer l'eau de mer, d'autres pour faire sortie l'eau
> douce d'autres pour simplement contrôler le niveau style chasse de la baie
> du mont Saint-Michel.
>
>
> Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
> Le 10/01/2018 à 00:16, althio a écrit :
>
>
> Par analogie, il faudrait quelque chose comme waterway=tidal_gate
>
> tide gate ou floodgate semble plus courant en anglais.
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> à votre avis on part plutôt sur floodgate parce que cela existe déjà ou sur
> un tidegate car plus lié au marée
>
> à plus
>
> Vinber
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [Talk-de] OpenRouteServcice und Autoverlade auf Bahn...

[chris66]

Am 18.01.2018 um 12:09 schrieb pbnoxious:


wenn man sich die Autoverladung am Furkapass anschaut, dann sieht man,
dass dort extra ein zusätzlicher Weg für die Autoverladung angelegt
wurde [1], der explicit "motocar=yes" stehen hat. Zudem wurden auch die
Zufahrtsstraßen (z.B. [2]) zur Autoverladung eingezeichnet, so dass die
Strecke nicht unterbrochen ist und tatsächlich darüber geroutet werden kann.


Schön. Was mich wundert:

Als Duration ist 0:20 angegeben, OSM-Graphhopper meldet aber dass die 
Fahrt 0:59 dauert.


Außerdem fehlen da noch Angaben dass der Transport nicht kostenlos ist
(fee=yes und/oder toll=yes).

Bei vielen Navis kann man einstellen, dass Mautstraßen vermieden werden 
sollen. Das geht aber natürlich nur, wenn die Strecken auch entsprechend

getaggt sind.

Chris

[1] https://www.openstreetmap.org/way/304571117



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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-18, 13:30 GMT, Marián Kyral wrote:
> Tam je problém, pravidla pravopisu se občas mění a záleží jak 
> se k tomu postaví místní samospráva (ta co pojmenovává ulice).

Point nebylo velké nebo malé písmeno (a tady je zcela nepochybně 
velké, protože se jedná o bývalou hospodu Jáma, 
https://www.openstreetmap.org/way/4387743), ale jednopísmenová 
předložka, která si zaslouží oddělit od druhého slova 
nezlomitelnou mezerou, což je co jsem v tom textu měl.

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Do not long for the night, when people vanish in their place.
Be careful, do not turn to evil; for you have preferred this to
affliction.
  -- Job 36:20f (NASB)


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

Re: [OSM-talk-fr] Écluses et portes à flots

[Vincent Bergeot]

Bonjour,

Le 10/01/2018 à 22:17, osm.sanspourr...@spamgourmet.com a écrit :

Flood control et non flow control.
flow_control=water_level 
 ? 
contrôle du niveau de l'eau
waterway=low_weir 
 ? seuil bas


Semblent là aussi surtout utilisé en eaux douces.



donc si l'on part du principe que les divers tags existants ne sont pas 
"satisfaisants", que celui qui semble le plus correct pourrait être :
waterway=tidegate (la définition semble bien coller : 
https://en.wiktionary.org/wiki/tide_gate), plus peut-être un complément 
pour préciser le sens ?


Quelle est la "bonne" manière de continuer :

la liste tagging,
je me prends trop la tête, je fais et je documente sur le wiki (je 
récupère une photo pour illustrer également !)


merci
Bonne journée




Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :


Bonsoir,

ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à 
de l'inondation, du déluge (de ce que j'ai compris je ne suis pas 
assez fluent en anglais !!!).


Alors que les portes à flots j'ai l'impression que c'est quelque 
chose de plus régulier, à chaque marée, soit pour maintenir de l'eau 
dans un port par exemple soit pour empêcher l'eau de mer de venir 
"polluer" de l'eau douce (zone marécageuses par exemples).




Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :


Ça me plait, ça pourrait être utilisé pour les formes de raboub et 
les seuil des ports me semble-t-il.


Pour le moment mes recherches sur Brest et Lorient n'ont rien donné 
: on a des eaux ou des formes de raboub mais la séparation se fait 
par la vertu du Saint-Esprit.


Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.

Il faudrait presque une info complémentaire car certaines "écluses" 
sont faites pour faire entrer l'eau de mer, d'autres pour faire 
sortie l'eau douce d'autres pour simplement contrôler le niveau 
style chasse de la baie du mont Saint-Michel.



Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à 
de l'inondation, du déluge (de ce que j'ai compris je ne suis pas 
assez fluent en anglais !!!).


Alors que les portes à flots j'ai l'impression que c'est quelque 
chose de plus régulier, à chaque marée, soit pour maintenir de l'eau 
dans un port par exemple soit pour empêcher l'eau de mer de venir 
"polluer" de l'eau douce (zone marécageuses par exemples).



Le 10/01/2018 à 00:16, althio a écrit :



Par analogie, il faudrait quelque chose comme waterway=tidal_gate

tide gate ou floodgate semble plus courant en anglais.

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki


à votre avis on part plutôt sur floodgate parce que cela existe déjà 
ou sur un tidegate car plus lié au marée


à plus

Vinber




___
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



--
Vincent Bergeot

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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Imre Samu]

>What can I as a map editor do to keep these data files to a reasonable
size without compromising  data quality?

According to the "Lean thinking" (
https://en.wikipedia.org/wiki/Lean_thinking ) we should focus on
" eliminating waste"
Waste is:
*  Any polygon or  tagging errors ( because we can't use this information,
and need lot of space or processing resources )   or any from this:
https://wiki.openstreetmap.org/wiki/Error_categories ;  etc
*  or any mapping errors ( bad street names ;  routing problems: waste for
users   )
*  or any not "UpToDate" data/information  ( old phone numbers -   it is
useless,  so it is waste )

some examples:
http://area.jochentopf.com/stats/
- Errors: Intersections
- Errors: Duplicate nodes
- Errors: Duplicate segments (* ~160.000*)
- Errors: Open rings  ( ~9.000)
- Errors: Inner rings with same tags as outer rings
- Errors: Wrong role (  *~ 700.000 *)

some key problems:  ( unused/bad keys is a waste )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#problem
( Keys with possibly problematic characters )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#space
 ( Keys with whitespace )
- or my favorite:
---  https://taginfo.openstreetmap.org/keys/latitude#values
---  https://taginfo.openstreetmap.org/keys/LAT#values

And we have lot of low quality imports we should fix.

>What can I as a map editor

imho:
Any quality assurance work helps a lot:
https://wiki.openstreetmap.org/wiki/Quality_assurance
so fixing data problems in your area helps "eliminating waste"and  less
waste is good for data size


Imre



2018-01-18 6:14 GMT+01:00 Oleksiy Muzalyev :

> Good morning,
>
> I started to experiment with the OSM data [1] on a local computer, and I
> begin to realize how big these data files are. It takes quite a while to
> load into the local database just the data for one country.
>
> What can I as a map editor do to keep these data files to a reasonable
> size without compromising  data quality? I mean in the sense, - take care
> of the pennies and the pounds will take care of themselves?
>
> I could think of the following three approaches so far:
>
> - using as short an URL as possible, website=http://somewebsite.com
> instead of website=http://www.somewebsite.com , three characters less; [2]
>
> - correct phone number ISO format, phone=+12 345 678 90 12 instead of
> phone=+12 (345) 678 90 12 , two characters less;  [3]
>
> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with consequent
> verification of its geometry;
>
> What else, if anything, could be done?
>
> [1] https://wiki.openstreetmap.org/wiki/Downloading_data
> [2] https://wiki.openstreetmap.org/wiki/Key:website
> [3] https://wiki.openstreetmap.org/wiki/Key:phone
>
> With best regards,
> Oleksiy
> osm: Alex-7
>
> ___
> 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-transit] Uploading public transport data on OSM

[Stephen Sprunk]

Agreed; ref:gtfs just won't work, and ref:OPER probably would. 

I was originally thinking in terms of some gtfs:key tags for imported
data, similar to tiger:key tags.  Once you consider multiple objects
could be merged, though, that would likewise need to change to
gtfs:OPER:key.  But do we need such import tags if we can directly put
the data directly into normal tags, such as your ref:OPER?  My first
thought was no, but perhaps it could help OSM edits survive future
imports of lower-quality GTFS data? 

>From the other side, how can we design this so that stops removed from
one or more GTFS feeds can be properly updated in OSM?  I was thinking a
gtfs:OPER:importdate tag, and once you're done adding/updating all the
objects in the latest GTFS feed, you can then query for objects still
showing a previous import date.  But there is probably a better way. 

S 

On 2018-01-16 15:17, Jo wrote:

> That is why I think it's important not to go with ref:gtfs, but use 
> ref:operator1, ref:operator2. Where operator1 and operator2 are the names or 
> short names for the different operators. In many cases you'll find that these 
> refs are also what the public sees on the stops (if the operators decide to 
> put it there) or in internet urls when using the operator's website.
> 
> Here in Belgium, we have 3 operators extending into the other operator's 
> mostly served area and some lines extend into neighbouring countries, so we 
> had to namespace the ref tag a few years ago, already. 
> 
> Polyglot 
> 
> 2018-01-16 22:07 GMT+01:00 Stephen Sprunk :
> 
>> AFAIK, the operator ID is only guaranteed to be unique within a single GTFS 
>> feed, but it's reasonably safe to assume they'll also be unique between 
>> feeds with overlapping geographical areas.  It's probably not safe to assume 
>> that's transitive. 
>> 
>> Where operators don't cooperate and produce a single joint feed, you'll 
>> inevitably face the "same" stops appearing in multiple feeds.  Imagine a 
>> single roadside bus stop pole with signs from two or three different bus 
>> operators on it, and that pole would have a different ID and probably even 
>> different lat/long in each feed.  Ideally, a local OSM editor would be able 
>> to merge them into a single stop object--and that merger would survive later 
>> bulk imports from all those GTFS feeds.  This would cut down on map clutter 
>> and allow routing apps to more easily recognize transfers, but I'm not sure 
>> how to design such a schema. 
>> 
>> It's been a while since I read the spec, but I think GTFS also has a similar 
>> concept to stop_areas, and that will probably have similar problems to 
>> stops. 
>> 
>> Routes appear simpler to deal with since they're unique to each operator, 
>> but they're inherently built on top of stops (or stop_areas), so they may 
>> present new problems when we get there. 
>> 
>> S

-- 
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] How to teach novices about optimal changeset size?

[althio]

I looked for similar issues and apparently it was already discussed,
considered back and forth and modified in iD.
https://github.com/openstreetmap/iD/issues/703
https://github.com/openstreetmap/iD/issues/1598
https://github.com/openstreetmap/iD/issues/2251#issuecomment-180469055

I don't know the effect of this recent modification
https://github.com/openstreetmap/iD/commit/437893ebb8b31e033e6544f0cc343725c4d6a0fd
but it might change a bit the behaviour of iD with open changesets.

-- althio


On 17 January 2018 at 22:26, Dave F  wrote:
> This a purely an iD problem. It should be down to their core programmers to
> sort it out.
> We should be encouraging users, especially newbies, to save frequently.
> Potlatch does this without the problem of numerous changesets.
>
> DaveF
>
>
> On 17/01/2018 13:26, Michał Brzozowski wrote:
>
> Many new users have a habit of e.g. sending one or few objects per
> changeset, resulting in a dozen or even more changesets per day. Obviously
> this makes them PITA to review quickly in Achavi or whatever tool you use.
>
> This habit is probably caused by non-knowledge of how auto-save works in iD
> (which makes the work reasonably secure), as well as just not knowing better
> thus forming their own judgement.
>
> How should we teach about optimal changeset size? This is quite tricky - how
> we would define it?
>
> Can the iD nudge users towards better practice? (Linking to Good changeset
> comments wiki page would be useful as well)
>
> Michał
>
>
> ___
> 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-pt] Talk-pt Digest, Vol 97, Issue 2

[Nuno Caldeira]

Bem vindo,

Se precisar de ajuda relativamente ao OSM ou Mapillary esteja à vontade.
Não entendi a sua dúvida relativamente aos sinais de trânsito. Estão a ser
incorrectamente detectados no Mapillary ou no OSM os que estão
representados estão incorrectos?
Caso queira um mount para utilizar o telemóvel para capturar imagens para o
Mapillary, pode solicitar um para carro ou bicicleta, neste link
https://docs.google.com/forms/d/1aOVJ8dvRsYahpW4k4hW4XRYGMZncmUWl4glpEr6p-pM/viewform?edit_requested=true


Em 18/01/2018 12:00 da tarde,  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. Apresentação de José Flor - OzFlor
>   (José António Flor de Sousa)
>2. Re: Apresentação de José Flor - OzFlor (Nelson A. de Oliveira)
>3. Re: Apresentação de José Flor - OzFlor (Pedro Lima)
>4. Re: Apresentação de José Flor - OzFlor (Marcos Oliveira)
>
>
> --
>
> Message: 1
> Date: Wed, 17 Jan 2018 12:20:37 +
> From: José António Flor de Sousa 
> To: "talk-pt@openstreetmap.org" 
> Subject: [Talk-pt] Apresentação de José Flor - OzFlor
> Message-ID:
>  KORP216.PROD.OUTLOOK.COM>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Bom dia ao grupo,
>
>
> Sou o José Flor, o nick na internet e por ai fora é OzFlor.
>
> Comecei recentemente na here seguido de openstreetmap e mapillary.
>
>
> Ainda sou novo por aqui e aos poucos vou entendendo como se faz. Irei ter
> duvidas que procurarei informar. Assim sempre que estiver editando peço
> ajuda quando o necessitar.
>
>
> Iram verificar que vou editar em 5 países porque é por ai que eu tenho
> andado e conheço as áreas em volta.
>
>
> Os meus interesses são diversos, parapente ciência com astronomia sem
> faltar, montanhas e natureza em geral. Electrónica já deixei de parte onde
> tinha muito material de aulas em fóruns que agora se perderam. Meu ultimo
> trabalho por conta própria era handyman. Agora estou parado e com muito
> tempo para viajar por ai.
>
>
> Ainda não sei que tipo de contribuição posso dar para o openstreetmap,
> conforme for entrando no site vou vendo se algo necessita de editar. Por
> agora estou fazendo o mapillary e verifico que tem muitos erros de sinais
> de transito que gostaria de editar nas minhas ou noutras imagens que me
> aparecerem pela frente.
>
>
> Grato por me aceitarem no grupo.
>
>
> José Flor
>
>
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20180117/b5fc3ad2/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Wed, 17 Jan 2018 10:31:26 -0200
> From: "Nelson A. de Oliveira" 
> To: OSM Portugal 
> Subject: Re: [Talk-pt] Apresentação de José Flor - OzFlor
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Oi, José.
> Seja bem vindo.
>
> Para os outros integrantes da lista, eu estava conversando
> anteriormente com o José e convidei-o a participar daqui, para tirar
> dúvidas e aprender como colaborar da melhor maneira possível com o
> OpenStreetMap.
>
> Obrigado e abraço!
>
>
>
> --
>
> Message: 3
> Date: Wed, 17 Jan 2018 12:49:28 +
> From: Pedro Lima 
> To: OSM Portugal 
> Subject: Re: [Talk-pt] Apresentação de José Flor - OzFlor
> Message-ID:
> 

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Petr Kadlec]

Ahoj,

4 nebo 3 (nebo 5, ale to je jiná práce, úplně bych to s tímhle nemíchal).

2018-01-18 10:46 GMT+01:00 Pavel Machek :

> ...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working
> group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v
> nazvech. A podle toho dal. Do te doby...
>

Budeme se ptát data working group, jestli chtějí v rámci celého světa v
názvem používat tečky, velká písmena, mezery, azbuku, … atd.? V českém
textu se prostě např. po jednopísmenných předložkách píše nezlomitelná
mezera. Ale tahle debata už tu proběhla.

Římské číslice v Unicode jsou úplně jiná situace a do názvů nepatří. Viz
Unicode Standard 10.0.0, kapitola 22.3 (s. 798) [1]; TLDR existují jen
kvůli východoasijským zemím: „For most purposes, it is preferable to
compose the Roman numerals from sequences of the appropriate Latin letters.
However, the uppercase and lowercase variants of the Roman numerals through
12, plus L, C, D, and M, have been encoded in the Number Forms block
(U+2150..U+218F) for compatibility with East Asian standards. Unlike
sequences of Latin letters, these symbols remain upright in vertical
layout. Additionally, in certain locales, compact date formats use Roman
numerals for the month, but may expect the use of a single character.“

-- Petr Kadlec / Mormegil

[1]: https://www.unicode.org/versions/Unicode10.0.0/ch22.pdf
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Mikoláš Štrajt]

Uliční cedule jsou navíc typicky psány CAPS LOCKem, takže to neulehčují.
--
Severák___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-es] Itinerarios de Semana Santa

[Luis García Castro]

Buenas,

Estando de acuerdo con bastante de lo que se ha dicho, creo que la clave
está en si son rutas consolidadas o no lo son. ¿Lo son?

La ruta a veces cambia por obras o temas de seguridad, pero hasta donde mi
ateísmo me alcanza creo en general son rutas fijas, ¿no?

No sabría dónde poner el corte, pero creo que las rutas "culturalmente"
importantes y consolidadas sí podrían estar reflejadas. Sería similar al
uso que se hace de route=historic

https://wiki.openstreetmap.org/wiki/ES:Relation:route#Otras

El matiz de que puedan ser verificadas sobre el terreno, bajo mi
interpretación, no sólo depende de que haya señales (y mucho menos de que
las señales estén puestas todo el año). Una ruta de este tipo es
perfectamente verificable.

Habría que buscar si hay cosas similares mapeadas, como rutas de carnavales
importantes.
​
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[john whelan]

source=Bing ad source=bing aren't the same when it comes to data
compression.  So getting a little more consistency in the tags would help.
Not so much the .osm format but certainly the compressed formats.

Cheerio John

On 18 January 2018 at 06:28, Martin Koppenhoefer 
wrote:

> 2018-01-18 12:01 GMT+01:00 Oleksiy Muzalyev :
>
>>
>>
>> You make sound 1.7% as not much, however, in say civil aviation or
>> maritime industries, consistent 1.7% of fuel efficiency increase would be a
>> breakthrough.
>>
>> I do not suggest, speaking figuratively, not breathing to save air. On
>> the contrary, I think the mapping just begins, at least in some areas. So
>> there will be much more, perhaps, times more data.
>>
>> At the same time, it would not harm to be mindful of data size issue and
>> to follow simple best practices, as the shortest URL possible, the ISO
>> phone format, etc.
>
>
>
>
> do not forget that computers get more powerful very quickly, compared to
> airplane efficiency for example. Cost of RAM and Diskspace is constantly
> falling, as is raising transfer speed of our internet connections. Reducing
> detail to save on disk space isn't what I would recommend. With some
> patience, you can still import the whole planet on a 6 years old, lower end
> computer with slow HDD (takes approx. 2 weeks), if you need more speed,
> invest in RAM and an SSD RAID array (all not so expensive any more). For a
> country extract, don't expect it to import within a few minutes, but
> besides the biggest countries, a few hours should suffice.
>
> Cheers,
> Martin
>
> ___
> 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-cz] Nedělitelné mezery v názvech ulic

[Marián Kyral]

-- Původní e-mail --
Od: MatějCepl 
Komu: talk-cz@openstreetmap.org
Datum: 18. 1. 2018 14:02:59
Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
"On 2018-01-18, 10:18 GMT, Marián Kyral wrote:
> Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1.
> máje", "Kpt. Jaroše", "Nám. Svobody"...

Já jsem měl na mysli spíše ulici V jámě.
"



Tam je problém, pravidla pravopisu se občas mění a záleží jak se k tomu
postaví místní samospráva (ta co pojmenovává ulice).

Někde se snaží mít to dle pravidel, jinde lpí na starém názvu a někde to
neřeší a píší si to jak chtějí - jinak je to v KM, jinak v registrech, půlka
cedulí tak, druhá půlka jinak. Už nevím, kde jsem to viděl/četl, ale stalo
se, že zastupitelé schválili určitý název, ale do KM se (zřejmě chybou
úředníka) dostalo něco trochu jiného.





Pro případ výše jsou podle mně možné obě možnosti, záleží na kontextu:


V jámě - v nějaké obecné rýze, která jámu připomíná


V Jámě - dané místo je jmenuje Jáma.





Bez bližší znalosti místa je těžké říct, jak je to správně. A už vůbec
nedokáži říct, odkud se to má brát.




Marián




"
Matěj
--
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

Quod fuimus, estis; quod sumus, vos eritis.


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

[OSM-talk-fr] serveur opéré par la Fondation [Re: Première réunion du bureau de l'OSMF ...]

[Benoit Fournier]

> Severin Menard  :
>> a priori l'instance de Mumble utilisée est celle du serveur de l'ONG HOT US 
>> Inc.

Vincent Privat  :
> ... pardon ? ça pourra être la première question à poser au board: pourquoi 
> ne pas mettre en place un serveur opéré par la Fondation et localisé en 
> dehors des US ?

De mon point de vue, ce n'est pas la première question à poser, et ce
n'est pas une question pour le board (plutôt pour OWG - Working Group
"Operations").


> pourquoi ne pas mettre en place un serveur localisé en dehors des US ?

Le serveur me semble localisé en Europe, pas vous ? Un serveur de hetzner.de ?
Et sinon, quelle différence ? (ça peut être bon d'expliciter les
justifications de manière raisonnée, pour éviter les interprétations
hasardeuses, par exemple d'être incorrectement assimilé à de
l'anti-américanisme trop primaire).


> pourquoi ne pas mettre en place un serveur opéré par la Fondation

Ensuite, je ne vais pas répondre à leur place, mais des réponses
possibles sont :
Parce que c'est pragmatique ? Parce que l'usage ne le justifie pas ?
Parce que personne ne l'a demandé ? On met le matériel à disposition,
vous pouvez le faire ?
Pour un exemple de discussion sur le sujet (canaux de communication
"chats" de type IRC/Mattermost/Slack/Jabber/...) et donc les
réflexions et positions des membres du Working Group Operations :
https://github.com/openstreetmap/operations/issues/128#issue-192860779
https://github.com/openstreetmap/operations/issues/128#issuecomment-264404220
https://github.com/openstreetmap/operations/issues/128#issuecomment-266739577

D'un autre côté, et toujours mon avis personnel, c'est que des
services opérés par des tiers, la communauté ou des organismes, et non
pas directement par la Fondation, il y en a beaucoup dans l'écosystème
OSM et que c'est plutôt sain.
OSM-FR fait tourner uMap, Osmose, les tuiles FR et HOT, HOT fait
tourner un Tasking Manager et un Mumble, iD est financé par Mapbox,
JOSM est en Allemagne, Geofabrik propose des services et outils
qualité, BBBike des extracts, thunderforest le rendu cycle, Mapbox
avec OSMCha, ... et Github fait tourner beaucoup de code pour beaucoup
de projets.

Si des aspects stratégiques ne sont pas bien couverts, il faut ouvrir
la discussion avec le groupe Operations OWG.

Benoît
contributeur et bénévole et membre à dimension variable de OSM-FR *et*
OSMF/SotM *et* HOT *et* CartONG.

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-18, 10:18 GMT, Marián Kyral wrote:
> Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1. 
> máje", "Kpt.  Jaroše", "Nám. Svobody"...

Já jsem měl na mysli spíše ulici V jámě.

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Quod fuimus, estis; quod sumus, vos eritis.


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

Re: [Talk-es] Itinerarios de Semana Santa

[Jesús Gómez Fernández]

Una cuestión parecida se trató en relación a la incorporación de rutas
turísticas promocionadas en folletos por parte de algunos Ayuntamientos o
provincias y que no llevan ninguna señalización sobre el terreno: por
ejemplo, la ruta modernista en Barcelona, rutas del vino, ruta del
románico, etc. En estos casos es muy difícil verificar el itinerario y si
estas perduran o cambian al antojo de nuevas estrategias turísticas.
Otra cosa serían rutas como la del Camino de Santiago, el Camino del Cid o
el Camino Lebaniego, que están bien consolidadas y señaladas.

En el caso de las procesiones de Semana Santa, carreras deportivas o
itinerarios en fiestas opino que a la larga son muy difíciles de gestionar
en OSM teniendo en cuenta que hay que lidiar con relaciones que pueden
cambiar o romperse. Y si el número y variedad de itinerarios es grande
llega a ser un problema tenerlas actualizadas.

Saludos,
Jesús Gómez

El 18 de enero de 2018, 13:17, Jesús Lopez 
escribió:

> De acuerdo con Emilio. No considero que este tipo de actividades (ni
> religiosas ni deportivas) entre dentro de la filosofía de lo que es OSM.
> Saludos
> Jesús
>
> El 18 ene 2018, a las 12:07, Emilio Gómez Fernández <
> emilio.gomez.f...@gmail.com> escribió:
>
> Considero que este y otros casos similares (carreras populares, marchas
> ciclistas, etc.)  iría contra uno de los puntos de buenas prácticas de
> OpenSetreetMap: el de "No cartografiar acontecimientos o elementos
> históricos" [1] (salvo excepciones muy discutidas).
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%
> A1cticas#No_mapear_acontecimientos_o_elementos_hist.C3.B3ricos
> 
>
>
>
> 
> Un saludo.
>
> 
>
>
> El 18 de enero de 2018, 11:53, dcapillae  escribió:
>
>> Saludos.
>>
>> Traslado a la lista una cuestión que se ha suscitado a raíz de este
>> conjunto
>> de cambios: https://www.openstreetmap.org/changeset/55352834
>>
>> ¿Os parece que los itinerarios de Semana Santa son susceptibles de ser
>> mapeados con una relación de ruta? De ser así, ¿qué tipo de ruta usaríais?
>>
>> Hay quien piensa que esta información no es verificable sobre el terreno,
>> que es cambiante de año en año y, por tanto, no debería incluirse en la
>> base
>> de datos de OSM. Según el wiki, una ruta consiste en un recorrido
>> «generalmente predeterminado y de público conocimiento»:
>> https://wiki.openstreetmap.org/wiki/ES:Relation:route
>>
>> ¿Os parece correcto incluir los itinerarios de Semana Santa en la base de
>> datos de OSM? De ser así, ¿cómo los mapearíais?
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

[Sébastien Dinot]

Bonjour,

Le contributeur vient de réagir que les courriers postaux devaient être 
adressés à Mios et non à Lacanau-de-Mios. J'ai donc corrigé dans la foulée les 
adresses. Problème résolu.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

[Philippe Verdy]

Au sein d'une agglomération on a aussi un niveau de place=suburb pour
qualifier les anciens villages absorbés par une commune, ça donne un niveau
en plus de neighbourhood (et hamlet qui devrait rester rural je pense).
Le cas du Japon, de la Chine, de la Corée ou de l'Inde avec leur mégapoles
ayant de nombreuses subdivisions internes peut aussi nous inspirer.

Le 18 janvier 2018 à 13:02, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 18 janv. 2018 à 09:57, erwan salomon  a écrit :
> >
> > salut,
> >
> > si je comprend bien voici un cas similaire sans doute plus explicite :
> > https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
> > (avec la traduction bretonne dessous)
> > ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite
> autour : https://www.openstreetmap.org/way/176823228 )
> > - [ attention village dans le language courant en bretagne désigne
> quelque chose d’encore plus petit, ne jamais dire à un breton qu’il habite
> dans un village il le prendra mal ]
> > alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
> > mais globalement ce sont 2 communes qui font partie d’une agglomération
> > en tant que tel elles ont un nom et une adresse postale distincte (sinon
> il y aurait des doublon de nom de rue)
> > mais la gestion administrative se fait par l’agglomération (c’est la
> mairie de Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les
> habitant de Fort-Bloqué vote pour le maire de Plœmeur)
> > un quartier c’est en général plus continu avec les quartiers voisins
> dans le langage courant, mais l’agglomération peut en effet diviser sa
> surface en quartier pour en répartir la gestion et procéder à des réunions
> de quartiers
> > il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici
> c’est l’inverse
> > quand à la gestion par Osmose, la je suis incompétent pour te donner des
> conseils
>
> Sur le principe, il est correct de classer Fort-Bloqué dans la catégorie «
> village » (de 100 à 10 000 habitants en France, selon le dernier consensus)
> dans OSM, indépendamment de ce qu’en fait l’administration. L’obligation de
> lui adjoindre des codes et une population doit se limiter aux unités
> administratives définies par l’Etat, mais les collectivités peuvent à leur
> en définir et les publier.
> Si une relation correspondant à une unité infra-communale officielle peut
> être tracée, tant mieux. Osmose doit prévoir ce genre de cas.
>
> Sur la liste anglophone, on débat de « hamlet » et « neighbourhood », ces
> derniers  étant présentés comme les anciens hameaux rejoints par
> l’urbanisation.
> C’est ce que j’applique depuis longtemps, aprés avoir mis des « hamlet »
> en ville.
>
>
> Christian R.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Itinerarios de Semana Santa

[Jesús Lopez]

De acuerdo con Emilio. No considero que este tipo de actividades (ni religiosas 
ni deportivas) entre dentro de la filosofía de lo que es OSM.
Saludos
Jesús

> El 18 ene 2018, a las 12:07, Emilio Gómez Fernández 
>  escribió:
> 
> Considero que este y otros casos similares (carreras populares, marchas 
> ciclistas, etc.)  iría contra uno de los puntos de buenas prácticas de 
> OpenSetreetMap: el de "No cartografiar acontecimientos o elementos 
> históricos" [1] (salvo excepciones muy discutidas).
> 
> [1] 
> https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%A1cticas#No_mapear_acontecimientos_o_elementos_hist.C3.B3ricos
>  
> 
> 
> 
>  
> 
> Un saludo.
>  
> 
> 
> 
> El 18 de enero de 2018, 11:53, dcapillae  > escribió:
> Saludos.
> 
> Traslado a la lista una cuestión que se ha suscitado a raíz de este conjunto
> de cambios: https://www.openstreetmap.org/changeset/55352834 
> 
> 
> ¿Os parece que los itinerarios de Semana Santa son susceptibles de ser
> mapeados con una relación de ruta? De ser así, ¿qué tipo de ruta usaríais?
> 
> Hay quien piensa que esta información no es verificable sobre el terreno,
> que es cambiante de año en año y, por tanto, no debería incluirse en la base
> de datos de OSM. Según el wiki, una ruta consiste en un recorrido
> «generalmente predeterminado y de público conocimiento»:
> https://wiki.openstreetmap.org/wiki/ES:Relation:route 
> 
> 
> ¿Os parece correcto incluir los itinerarios de Semana Santa en la base de
> datos de OSM? De ser así, ¿cómo los mapearíais?
> 
> 
> 
> -
> Daniel Capilla
> OSM user: dcapillae
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Itinerarios de Semana Santa

[Javier Sánchez Portero]

No estoy especialmente a favor ni en contra de mapear ese tipo de casos,
pero el argumento creo que no se aplica. No es lo mismo un acontecimiento
histórico que uno que ocurre de forma periódica (anual) en la actualidad.
Otra cosa es que la carrera deje de organizarse de forma definitiva. En ese
caso habría que eliminar la ruta.

El 18 de enero de 2018, 11:07, Emilio Gómez Fernández <
emilio.gomez.f...@gmail.com> escribió:

> Considero que este y otros casos similares (carreras populares, marchas
> ciclistas, etc.)  iría contra uno de los puntos de buenas prácticas de
> OpenSetreetMap: el de "No cartografiar acontecimientos o elementos
> históricos" [1] (salvo excepciones muy discutidas).
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%
> A1cticas#No_mapear_acontecimientos_o_elementos_hist.C3.B3ricos
>
>
>
> 
> Un saludo.
>
> 
>
>
> El 18 de enero de 2018, 11:53, dcapillae  escribió:
>
>> Saludos.
>>
>> Traslado a la lista una cuestión que se ha suscitado a raíz de este
>> conjunto
>> de cambios: https://www.openstreetmap.org/changeset/55352834
>>
>> ¿Os parece que los itinerarios de Semana Santa son susceptibles de ser
>> mapeados con una relación de ruta? De ser así, ¿qué tipo de ruta usaríais?
>>
>> Hay quien piensa que esta información no es verificable sobre el terreno,
>> que es cambiante de año en año y, por tanto, no debería incluirse en la
>> base
>> de datos de OSM. Según el wiki, una ruta consiste en un recorrido
>> «generalmente predeterminado y de público conocimiento»:
>> https://wiki.openstreetmap.org/wiki/ES:Relation:route
>>
>> ¿Os parece correcto incluir los itinerarios de Semana Santa en la base de
>> datos de OSM? De ser así, ¿cómo los mapearíais?
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Itinerarios de Semana Santa

[dcapillae]

Gracias, Emilio.

Creo que la práctica de no cartografiar elementos históricos se refiere a
elementos del «pasado histórico». En el caso de los itinerarios de Semana
Santa no estaríamos ante un elemento histórico, sino ante un evento
religioso o cultural del presente y que ocurre todos los años.

Ahora bien, quizás hayas tocado una de las claves para no incluir estos
itinerarios en la base de datos de OSM, el considerar estos itinerarios no
como recorridos predeterminados ni de interés público sino como eventos
culturales. En tal caso, como justificación para no mapear los itinerarios
de Semana Santa podría valernos la primera parte de tu argumento: no mapear
carreras populares, marchas ciclistas ni eventos similares.



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

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

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

[Christian Rogel]

> Le 18 janv. 2018 à 09:57, erwan salomon  a écrit :
> 
> salut,
> 
> si je comprend bien voici un cas similaire sans doute plus explicite :
> https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
> (avec la traduction bretonne dessous)
> ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite 
> autour : https://www.openstreetmap.org/way/176823228 )
> - [ attention village dans le language courant en bretagne désigne quelque 
> chose d’encore plus petit, ne jamais dire à un breton qu’il habite dans un 
> village il le prendra mal ]
> alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
> mais globalement ce sont 2 communes qui font partie d’une agglomération
> en tant que tel elles ont un nom et une adresse postale distincte (sinon il y 
> aurait des doublon de nom de rue)
> mais la gestion administrative se fait par l’agglomération (c’est la mairie 
> de Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les habitant de 
> Fort-Bloqué vote pour le maire de Plœmeur)
> un quartier c’est en général plus continu avec les quartiers voisins dans le 
> langage courant, mais l’agglomération peut en effet diviser sa surface en 
> quartier pour en répartir la gestion et procéder à des réunions de quartiers
> il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici c’est 
> l’inverse
> quand à la gestion par Osmose, la je suis incompétent pour te donner des 
> conseils

Sur le principe, il est correct de classer Fort-Bloqué dans la catégorie « 
village » (de 100 à 10 000 habitants en France, selon le dernier consensus) 
dans OSM, indépendamment de ce qu’en fait l’administration. L’obligation de lui 
adjoindre des codes et une population doit se limiter aux unités 
administratives définies par l’Etat, mais les collectivités peuvent à leur en 
définir et les publier.
Si une relation correspondant à une unité infra-communale officielle peut être 
tracée, tant mieux. Osmose doit prévoir ce genre de cas.

Sur la liste anglophone, on débat de « hamlet » et « neighbourhood », ces 
derniers  étant présentés comme les anciens hameaux rejoints par l’urbanisation.
C’est ce que j’applique depuis longtemps, aprés avoir mis des « hamlet » en 
ville.


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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Martin Koppenhoefer]

2018-01-18 12:01 GMT+01:00 Oleksiy Muzalyev :

>
>
> You make sound 1.7% as not much, however, in say civil aviation or
> maritime industries, consistent 1.7% of fuel efficiency increase would be a
> breakthrough.
>
> I do not suggest, speaking figuratively, not breathing to save air. On the
> contrary, I think the mapping just begins, at least in some areas. So there
> will be much more, perhaps, times more data.
>
> At the same time, it would not harm to be mindful of data size issue and
> to follow simple best practices, as the shortest URL possible, the ISO
> phone format, etc.




do not forget that computers get more powerful very quickly, compared to
airplane efficiency for example. Cost of RAM and Diskspace is constantly
falling, as is raising transfer speed of our internet connections. Reducing
detail to save on disk space isn't what I would recommend. With some
patience, you can still import the whole planet on a 6 years old, lower end
computer with slow HDD (takes approx. 2 weeks), if you need more speed,
invest in RAM and an SSD RAID array (all not so expensive any more). For a
country extract, don't expect it to import within a few minutes, but
besides the biggest countries, a few hours should suffice.

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

Re: [OSM-talk] place=hamlet in cities

[Dave F]

On 18/01/2018 00:34, Mike N wrote:

On 1/17/2018 6:53 PM, Dave F wrote:
Have you been in contact with the two contributors to see if they can 
revoke/reupload?
I presume it came from a database. If it's still available it can be 
amended as required.


  At this point it would be much better to just manually fix anything 
that doesn't look right - it will be much more up to date than trying 
to conflate any new data with potentially edited data which could be a 
mix of nodes and areas.


" and have not been updated since." means they haven't bee edited. The 
update edits appears to just add unnecessary 'is_in' tags, but hey if 
you wish to waste hours of your time ticking them off one by one, knock 
yourself out.


DaveF.


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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Komяpa]

Hi,

Please don't try to save on keeping data in text format, this is a path to
removing source= tags and starting to use abbreviations in name for the
sake of file size, ignoring the fact that each object has much longer
iso8601 timestamp attached to it.

Use proper format, like .osm.pbf, that employs text strings compression,
binary representation of everything numeric and fixes the issue of 'spaces
around country code' and 'www.' by GZIPing the contents.

чт, 18 янв. 2018 г. в 14:03, Oleksiy Muzalyev :

> On 18.01.18 06:58, Mark Wagner wrote:
> > On Thu, 18 Jan 2018 06:14:17 +0100
> > Oleksiy Muzalyev  wrote:
> >
> >> Good morning,
> >>
> >> I started to experiment with the OSM data [1] on a local computer,
> >> and I begin to realize how big these data files are. It takes quite a
> >> while to load into the local database just the data for one country.
> >>
> >> What can I as a map editor do to keep these data files to a
> >> reasonable size without compromising  data quality? I mean in the
> >> sense, - take care of the pennies and the pounds will take care of
> >> themselves?
> >>
> >> I could think of the following three approaches so far:
> >>
> >> - using as short an URL as possible, website=http://somewebsite.com
> >> instead of website=http://www.somewebsite.com , three characters
> >> less; [2]
> >>
> >> - correct phone number ISO format, phone=+12 345 678 90 12 instead of
> >> phone=+12 (345) 678 90 12 , two characters less;  [3]
> >>
> >> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with
> >> consequent verification of its geometry;
> >>
> >> What else, if anything, could be done?
> > Honestly, the best thing you can do is not worry about it.  The world
> > is a big, complicated place.  The three bytes you save from shortening
> > a URL?  You'd need to repeat it 400 times to fit one extra gas station
> > on the map.
> >
> > As an experiment, I tried applying various data-saving
> > options to a park I've mapped.  I managed to reduce the size from
> > 1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
> > will vanish almost instantly this spring once I resume mapping
> > seasonal wetlands.
> >
> Mark,
>
> You make sound 1.7% as not much, however, in say civil aviation or
> maritime industries, consistent 1.7% of fuel efficiency increase would
> be a breakthrough.
>
> I do not suggest, speaking figuratively, not breathing to save air. On
> the contrary, I think the mapping just begins, at least in some areas.
> So there will be much more, perhaps, times more data.
>
> At the same time, it would not harm to be mindful of data size issue and
> to follow simple best practices, as the shortest URL possible, the ISO
> phone format, etc.
>
> Best regards,
> Oleksiy
> osm: Alex-7
>
>
>
> ___
> 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] OpenRouteServcice und Autoverlade auf Bahn...

[pbnoxious]

Hallo,

wenn man sich die Autoverladung am Furkapass anschaut, dann sieht man,
dass dort extra ein zusätzlicher Weg für die Autoverladung angelegt
wurde [1], der explicit "motocar=yes" stehen hat. Zudem wurden auch die
Zufahrtsstraßen (z.B. [2]) zur Autoverladung eingezeichnet, so dass die
Strecke nicht unterbrochen ist und tatsächlich darüber geroutet werden kann.

In Slovenien ist das nicht der Fall, hier existieren zwar
Route-Relationen mit "route=shuttle_train" [3], aber keine Tags auf der
Eisenbahnstrecke. Zudem sind hier keine Zufahrten eingezeichnet, es ist
also gar kein durchhgängiger Weg vorhanden (woher soll der Router denn
wissen, dass er hier auf die Zugstrecke springen kann). Es ist also
klar, dass hier momentan nicht entlang geroutet werden kann, sondern
dafür erst die Daten verändert werden müssen.

Ich bin mir nicht sicher ob der zusätzliche Weg (wie am Furkapass)
wirklich sein muss, da sollte sich besser jemand mit mehr Ahnung zum
Routing melden.

Grüße
pbnoxious


[1] https://www.openstreetmap.org/way/304571117
[2] https://www.openstreetmap.org/way/327715897
[3] https://www.openstreetmap.org/relation/7269394

(Entschuldigung für eventuellen Doppelempfang, hatte zuerst nicht an die
Liste geantwortet)



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

Re: [Talk-es] Itinerarios de Semana Santa

[Emilio Gómez Fernández]

Considero que este y otros casos similares (carreras populares, marchas
ciclistas, etc.)  iría contra uno de los puntos de buenas prácticas de
OpenSetreetMap: el de "No cartografiar acontecimientos o elementos
históricos" [1] (salvo excepciones muy discutidas).

[1]
https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%A1cticas#No_mapear_acontecimientos_o_elementos_hist.C3.B3ricos



Un saludo.



El 18 de enero de 2018, 11:53, dcapillae  escribió:

> Saludos.
>
> Traslado a la lista una cuestión que se ha suscitado a raíz de este
> conjunto
> de cambios: https://www.openstreetmap.org/changeset/55352834
>
> ¿Os parece que los itinerarios de Semana Santa son susceptibles de ser
> mapeados con una relación de ruta? De ser así, ¿qué tipo de ruta usaríais?
>
> Hay quien piensa que esta información no es verificable sobre el terreno,
> que es cambiante de año en año y, por tanto, no debería incluirse en la
> base
> de datos de OSM. Según el wiki, una ruta consiste en un recorrido
> «generalmente predeterminado y de público conocimiento»:
> https://wiki.openstreetmap.org/wiki/ES:Relation:route
>
> ¿Os parece correcto incluir los itinerarios de Semana Santa en la base de
> datos de OSM? De ser así, ¿cómo los mapearíais?
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Oleksiy Muzalyev]

On 18.01.18 06:58, Mark Wagner wrote:

On Thu, 18 Jan 2018 06:14:17 +0100
Oleksiy Muzalyev  wrote:


Good morning,

I started to experiment with the OSM data [1] on a local computer,
and I begin to realize how big these data files are. It takes quite a
while to load into the local database just the data for one country.

What can I as a map editor do to keep these data files to a
reasonable size without compromising  data quality? I mean in the
sense, - take care of the pennies and the pounds will take care of
themselves?

I could think of the following three approaches so far:

- using as short an URL as possible, website=http://somewebsite.com
instead of website=http://www.somewebsite.com , three characters
less; [2]

- correct phone number ISO format, phone=+12 345 678 90 12 instead of
phone=+12 (345) 678 90 12 , two characters less;  [3]

- deleting unnecessary nodes from a way (Shift-Y in JOSM) with
consequent verification of its geometry;

What else, if anything, could be done?

Honestly, the best thing you can do is not worry about it.  The world
is a big, complicated place.  The three bytes you save from shortening
a URL?  You'd need to repeat it 400 times to fit one extra gas station
on the map.

As an experiment, I tried applying various data-saving
options to a park I've mapped.  I managed to reduce the size from
1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
will vanish almost instantly this spring once I resume mapping
seasonal wetlands.


Mark,

You make sound 1.7% as not much, however, in say civil aviation or 
maritime industries, consistent 1.7% of fuel efficiency increase would 
be a breakthrough.


I do not suggest, speaking figuratively, not breathing to save air. On 
the contrary, I think the mapping just begins, at least in some areas. 
So there will be much more, perhaps, times more data.


At the same time, it would not harm to be mindful of data size issue and 
to follow simple best practices, as the shortest URL possible, the ISO 
phone format, etc.


Best regards,
Oleksiy
osm: Alex-7



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

[Talk-es] Itinerarios de Semana Santa

[dcapillae]

Saludos.

Traslado a la lista una cuestión que se ha suscitado a raíz de este conjunto
de cambios: https://www.openstreetmap.org/changeset/55352834

¿Os parece que los itinerarios de Semana Santa son susceptibles de ser
mapeados con una relación de ruta? De ser así, ¿qué tipo de ruta usaríais?

Hay quien piensa que esta información no es verificable sobre el terreno,
que es cambiante de año en año y, por tanto, no debería incluirse en la base
de datos de OSM. Según el wiki, una ruta consiste en un recorrido
«generalmente predeterminado y de público conocimiento»:
https://wiki.openstreetmap.org/wiki/ES:Relation:route

¿Os parece correcto incluir los itinerarios de Semana Santa en la base de
datos de OSM? De ser así, ¿cómo los mapearíais?



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

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

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Oleksiy Muzalyev]

On 18.01.18 10:01, Martin Koppenhoefer wrote:
2018-01-18 6:14 GMT+01:00 Oleksiy Muzalyev 
>:



- deleting unnecessary nodes from a way (Shift-Y in JOSM) with
consequent verification of its geometry;




please do not use SHIFT+y (simplify way / DouglasPeucker) because it 
doesn't know about the actual geometry, in particular sharp bends or 
curves in general will get worse, it will reduce overall accuracy 
(within the distance limit that you set/default, but ignoring angles). 
You will achieve better results by adjusting the ways manually. IMHO 
applying this algorithm to geometries other than those you added 
yourself is an automated edit and should generally be discouraged. 
There are some sensible usecases (serious "overnoding", particularly 
intermediate nodes in straight lines), but for every longer way (more 
than a screenfull in reasonable zoomlevel) you will typically not see 
all the effects, hence it's an automated edit.


Cheers,
Martin

Martin,

You are absolutely right. The Simplify way, Shift-Y, in JOSM, 
(Douglas-Peucker simplification) should be used only for own edits or 
for undeniable over-noding, i.e. a short direct line consisting from 
hundreds of nodes (probably from imports or kind of OCR editing).


Otherwise the lines and shapes will look angular.

I had to mention it myself. Thank you.

Best regards,
Oleksiy
osm: Alex-7


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

Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR

[Jiří Komárek]

Právěže EEA není bohužel aktuální. Například Národní přírodní rezervace 
Kosířské lomy tam není (vyhlášeno 15. dubna 2017), zatímco v databázi 
AOPK je (stejně tak jako na mapy.cz - 
https://en.mapy.cz/turisticka?x=17.0869388=49.5345400=15=base=2118557 
)



A nové verze shapefilu se v EEA objeví vždy jednou za hooodně dlouhý čas 
:-(



On 18.1.2018 10:24, Ha Noj wrote:

Jen bych chtěl upozornit, že na EEA aktuální data o Natuře, MCHÚ a
VCHÚ od AOPK jsou:

https://www.eea.europa.eu/data-and-maps/data/natura-8/natura-2000-spatial-data/natura-2000-shapefile-1
https://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-12/gis-data/cdda-shape-file

hanoj

Dne 17. ledna 2018 22:39 Jan Macura  napsal(a):

2018-01-17 22:17 GMT+01:00 Matej Lieskovský :

Ok, takže to chce jim napsat, zda to nechtějí všechno uvolnit pod CC-0,
nebo nám alespoň dát plošně výjimku podobnou jako nám dal IPR, ať to
nemusíme tahat přes WD?


Takže jestli si s nimi chceme dopisovat, tak to chce rozdělit na 2 části:
1) památné stromy: slušně je upozornit, že na vlastním webu publikovat data
pod jinou licencí, než na webu jiném nedává smysl
2) zbylé datasety: a) jestli by je nechtěli zveřejnit pod ODbL, protože je
šitá na míru datům a databázím, na rozdíl od CC, která se častěji používá
pro jiné typy děl, protože by to bylo kompatibilní s OSM a dalšími
databázemi, protože tím pořád bude zachována povinnost uvést původ, atd.
atp. nebo b) je prostě požádat o výslovný souhlas, že do OSM to importovat
lze [ref].

H.

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


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



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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Marián Kyral]

-- Původní e-mail --
Od: Michal Fabík 
Komu: OpenStreetMap Czech Republic 
Datum: 18. 1. 2018 11:09:54
Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
"2018-01-18 11:02 GMT+01:00 Jan Martinec :
> No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí na
> OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to zmapováno
i
> podle cedule (alt_name?).
>
> (Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím to
o
> dlouhém večeru přeložit:
> https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_
ground

Takhle jo, _i_ podle cedule, do alt_name. Prý by ale cedule (resp.
podoba názvu na ní) nemá sloužit jako zdroj pro name.
"



Jestli to spíše nebylo míněno tak, že do name nepatří "Tř. 1. máje", "Kpt.
Jaroše", "Nám. Svobody"...

To je pravda. Do name by se to mělo rozepsat.





Ale jinak nevidím důvod, proč do name tu ceduli nepřepsat.





Marián



"
--
Michal Fabík

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Michal Fabík]

2018-01-18 11:02 GMT+01:00 Jan Martinec :
> No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí na
> OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to zmapováno i
> podle cedule (alt_name?).
>
> (Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím to o
> dlouhém večeru přeložit:
> https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground

Takhle jo, _i_ podle cedule, do alt_name. Prý by ale cedule (resp.
podoba názvu na ní) nemá sloužit jako zdroj pro name.

-- 
Michal Fabík

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Martinec]

Dne 18.1.2018 v 09:17 Michal Fabík napsal(a):

2018-01-18 8:45 GMT+01:00 majka :

Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích pak
přesunout do name


Na cedulích? Jednou mně tady bylo řečeno, že cedule jsou irelevatní a
že směrodatná jsou data ČÚZK.



No, to se mi nezdá. ČÚZK je sice právně směrodatný zdroj, ale OSM stojí 
na OTGR, čili ověřitelnosti v terénu. Pokud je tam cedule, budiž to 
zmapováno i podle cedule (alt_name?).


(Tohle je kupodivu anglicky i slovensky, ale česky ne? No vida, zkusím 
to o dlouhém večeru přeložit:

https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground
)

Zdar,
HPM

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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[Charles MILLET]

C'est sûr que les deux exemples sont sans ambiguïtés mais au final on 
trouve beaucoup d'aménagements équivalents que je ne trouve pas plus 
ambiguë d’ailleurs l'illustration de la page footway ne comporte pas de 
panneau : https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway


Je comprends bien la tentation de s'appuyer sur des éléments concrets 
comme des panneaux mais je crois que je préfère encore débattre sur la 
nature d'un chemin et la pratique ;)


On 17/01/2018 18:35, marc marc wrote:

Bonsoir,

Le 17. 01. 18 à 15:19, Charles MILLET a écrit :

éviter les débats pour savoir si un voie est un footway ou un cycleway

ce serrait pourtant facile en se basant :
sur la largeur : trop étroit pour un véhicule -> path
sur les panneaux
footway
https://wiki.openstreetmap.org/wiki/File:Path-footdesignated.jpg
cycleway
https://wiki.openstreetmap.org/wiki/File:Path-bicycledesignated.jpg
et donc sans panneau ou vélo+piéton-> path


je ne sais pas elle fait consensus.

Hélas non.
https://wiki.openstreetmap.org/wiki/FR:Path_controversy
___
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

[OSM-talk] Invitation to Geo4All Webinar Fri Jan 19 - Get to know the YouthMappers

[Suchith Anand]

Dear colleagues,

Reminder of tomorrow's GeoForAll webinar on YouthMappers. Details below. I 
thank University of Colorado for hosting GeoForAll webinars. All welcome.

Best wishes,

Suchith

From: GeoForAll  on behalf of 
Moreno-sanchez, Rafael 
Sent: 12 January 2018 00:34
To: geofor...@lists.osgeo.org; l...@giscolorado.org; all_memb...@ucgis.org
Subject: [Geo4All] Geo4All Webinar Fri Jan 19 12:00 PM Central Mountain Time 
(7:00 PM GMT)

Hi everyone,
Happy New Year!

We are starting the year with the following great webinar.
As usual, we will record in post in the Geo4All YouTube Channel
https://www.youtube.com/channel/UCL1E2akvCNWP_nC0p5CpB8g/videos


Get to know the YouthMappers
(www.youthmappers.org)

Dr. Patricia Solis
Texas Tech University
Friday January 19th
12:00 PM Central Mountain Time (7:00 PM GMT)
Join URL:  https://ucdenver.zoom.us/j/550112761



Abstract
Capitalizing on web-based open geospatial technologies, YouthMappers seeks to 
cultivate a generation of young leaders to create resilient communities and  to 
define their world by mapping it. Uniting a global network of student-led 
chapters, now on 100 university campuses in 30 countries, we promote the 
creation and use of open data on open platforms in ways that directly address 
development challenges, both in the local community and around the world 
through remote collaborations. Mapping applications focus on a range of 
significant issues like food insecurity, public health, natural disasters, and 
peaceful development. The program supports university efforts to offer 
meaningful global learning experiences, build a socially engaged citizenry, 
enhance long-term scientific capacity around the world, and foster university 
student leadership. The program is supported by a grant from the United States 
Agency for International Development’s GeoCenter and co-founded by Texas Tech 
University, George Washington University and West Virginia University.   
www.youthmappers.org



__
Rafael Moreno, Ph.D.
Department of Geography and Environmental Sciences
University of Colorado Denver
Office: North Classroom 3524, Auraria Campus
Campus Box 172
1200 Larimer Street NC 3524
Denver, CO 80204
Phone: 303-315-7556
Fax 303-556-6197
Website: https://clas.ucdenver.edu/directory/faculty-staff/Rafael-Moreno












This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Pavel Machek]

On Wed 2018-01-17 13:49:08, Matej Lieskovský wrote:
> Ahoj!
> 
> Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu
> street relací a tak narážím na různé podivnosti v databázi, kterých bych si
> jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té
> samé ulice mají různé názvy, což chytá i takové prkotiny, jako je
> nedělitelná mezera (nbsp).
> 
> Vím, že se tady před rokem vedl flame na téma nedělitelných mezer a k
> žádnému konsenzu to (pokud vím) nevedlo.
> 
> Přijde mi rozumné, aby všechny segmenty ulice měly identické name tagy.
> Část důvodu, proč celé tyhle street relace dělám je i snaha o automatickou
> synchronizaci name: tagů napříč všemi segmenty. Když napíšu nbsp do
> tagů relace, tak mi to asi náhodní editoři nerozbijou a jsem ochoten to pak
> opravovat.
> 
> Co mám dělat?
> 
> 1) Odstraňuj nbsp z názvů ulic

1).

...Tedy ve skutecnosti... 1). Pripadne se zeptat na data working
group, co si o tom mysli, a jestli chteji v ramci celeho sveta nbsp v
nazvech. A podle toho dal. Do te doby...
Pavel

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

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[Charles MILLET]

J'aurais du creuser un peu, je vois que la page francophone dédiée 
living_street 
(https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street) 
cite cette relation.


On 18/01/2018 10:19, Charles MILLET wrote:

Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté 
de ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits 


https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 
n'est pas

nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de 
ne pas
se basé sur les spécificités locales pour considérer des valeurs 
implicites
de cette importance. Mais je voulais avoir vos avis avant d'en 
parler dans
la partie discussion ou directement avec le contributeur. Bon je 
pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas 
trouvé de

référence claire, ça pourra faire l'objet d'un rappel :)

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


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


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



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



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

Re: [Talk-cz] opendata Agentura ochrany přírody a krajiny ČR

[Ha Noj]

Jen bych chtěl upozornit, že na EEA aktuální data o Natuře, MCHÚ a
VCHÚ od AOPK jsou:

https://www.eea.europa.eu/data-and-maps/data/natura-8/natura-2000-spatial-data/natura-2000-shapefile-1
https://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-12/gis-data/cdda-shape-file

hanoj

Dne 17. ledna 2018 22:39 Jan Macura  napsal(a):
>
> 2018-01-17 22:17 GMT+01:00 Matej Lieskovský :
>>
>> Ok, takže to chce jim napsat, zda to nechtějí všechno uvolnit pod CC-0,
>> nebo nám alespoň dát plošně výjimku podobnou jako nám dal IPR, ať to
>> nemusíme tahat přes WD?
>
>
> Takže jestli si s nimi chceme dopisovat, tak to chce rozdělit na 2 části:
> 1) památné stromy: slušně je upozornit, že na vlastním webu publikovat data
> pod jinou licencí, než na webu jiném nedává smysl
> 2) zbylé datasety: a) jestli by je nechtěli zveřejnit pod ODbL, protože je
> šitá na míru datům a databázím, na rozdíl od CC, která se častěji používá
> pro jiné typy děl, protože by to bylo kompatibilní s OSM a dalšími
> databázemi, protože tím pořád bude zachována povinnost uvést původ, atd.
> atp. nebo b) je prostě požádat o výslovný souhlas, že do OSM to importovat
> lze [ref].
>
> H.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>

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

Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

[OSMDoudou]

Hello,

Can you help with the B) part of the discussion ?

What highway value is suitable for R50 ?

Now that I discovered the local implicit characteristics thanks to the answer 
to question A), trunk is probably right, but I wanted to ask your views 
nonetheless.

Thx.


-Original Message-
From: "Volker Schmidt" 
Sent: ‎18-‎01-‎18 09:39
To: "Tag discussion, strategy and related tools" 
Subject: Re: [Tagging] Way access mismatch relation route=bicycle

I suppose Osmose uses the country specific tables in [1]

The table for Belgium states that bicycle=no is implicit for "highway=trunk".

Hence the short way in question would need to have the additional tag 
"bicycle=yes" for bicycle routing to pass along that cycle lane.

The road signs out there seem to be consistent, there are "no-bicycle" sign 
along the ring road, except for this short piece.


Your second point regarding the road classification trunk is a different issue, 
that needs to be discussed with the Belgian community.


[1] https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions



On 17 January 2018 at 22:45, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

Hello,
 
This is a two-fold question in fact.
 
(A)
 
Osmose raises error "Way access mismatch relation route=bicycle" [1] on a 
segment of the R50 highway [2] [3].
 
I'm guessing it's because the segment is part of relation for a bike route but 
it's tagged as trunk (as the rest of R50), and a trunk would imply a 
restriction for bicycles.
 
Although, I see such an implication for motorways [4], I don't see it for 
trunks [5].
 
Do you know what causes the access mismatch, because I don't see it from the 
tags ?
 
(B)
 
This issue raises the question whether R50 should be tagged as trunk in the 
first place.
 
The Wiki page [6] refers to notions like "high performance" and road signs F9. 
But the road is limited to 70 km/h and there are no F9 signs on the entries and 
exits of R50, only C19 "No entry for pedestrians" and C11 + C9 "No entry for 
bicycles" + "No entry for mopeds (and mofas)", which tend to confirm it's not a 
trunk.
 
I wonder if primary wouldn't be more accurate classification, although the Wiki 
refers to a "highway linking large towns" [7], which is not the case here as 
the highway is a ring around the city not a road between cities.
 
What type of road would you qualify the entire R50 ?
 
Thx.
 
[1] http://osmose.openstreetmap.fr/en/error/15216104253
[2] http://www.openstreetmap.org/browse/way/251684307
[3] https://goo.gl/maps/khpwvm8kxQw
[4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
[5] https://wiki.openstreetmap.org/wiki/Trunk
[6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
[7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary

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

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[Charles MILLET]

Bonjour althio,

Ça répond complètement à ma question. J'étais totalement passé à coté de 
ce type de relation. Merci beaucoup pour l'éclairage :)


Je suis curieux de savoir pourquoi on n'y trouve pas l'ensemble des 
informations décrites dans la page des valeurs par défaut des 
restrictions d'accès 
(https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France).


On 17/01/2018 16:49, althio wrote:

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :

Un contributeur a précisé l'information suivante dans la page du Wiki
FR:Bicycle

"Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
nécessaire car valeur par défaut en France"

De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
se basé sur les spécificités locales pour considérer des valeurs implicites
de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
la partie discussion ou directement avec le contributeur. Bon je pense que
le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
référence claire, ça pourra faire l'objet d'un rappel :)

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


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


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



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

[Talk-it] ricerca su OSM: nuova mailing list e track accademica a SotM 2018

[Marco Minghini]

Ciao a tutti,

come sicuramente molti sapranno già, è stata creata una nuova mailing list
per avvicinare la comunità scientifica/accademica e la comunità di
utenti/mappatori OSM.
La pagina di regsitrazione è questa [1].

Approfitto per segnalare che quest'anno a State of the Map ci sarà, oltre
alle presentazioni "standard" (call già pubblicata qui [2]), anche una
track accademica - questo proprio per riconoscere l'importanza di OSM in
ambito scientifico e per cominciare a creare un link maggiore tra
ricercatori e comunità.

Sto organizzando gli ultimi dettagli della track accademica, di cui sono
responsabile. La call per gli abstract sarà pubblicata a brevissimo.

Marco

[1] https://lists.openstreetmap.org/listinfo/science
[2]
https://docs.google.com/forms/d/e/1FAIpQLScM9lUg8Z-qUpqcOcWzD1MpV708PPIl82hgdARECz1D_7sMbA/viewform

Marco Minghini, Ph.D.
GEOlab, Politecnico di Milano - DICA
Piazza Leonardo da Vinci 32, 20133 Milano (Italy)
+39 02 23996409
marco.mingh...@polimi.it
@MarcoMinghini 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Martin Koppenhoefer]

2018-01-18 6:14 GMT+01:00 Oleksiy Muzalyev :

>
> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with consequent
> verification of its geometry;




please do not use SHIFT+y (simplify way / DouglasPeucker) because it
doesn't know about the actual geometry, in particular sharp bends or curves
in general will get worse, it will reduce overall accuracy (within the
distance limit that you set/default, but ignoring angles). You will achieve
better results by adjusting the ways manually. IMHO applying this algorithm
to geometries other than those you added yourself is an automated edit and
should generally be discouraged. There are some sensible usecases (serious
"overnoding", particularly intermediate nodes in straight lines), but for
every longer way (more than a screenfull in reasonable zoomlevel) you will
typically not see all the effects, hence it's an automated edit.

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

Re: [OSM-talk-fr] Modification de la page FR:Bicyle concernant les voies piétonnes partagées

[Charles MILLET]

En fait c'est la condition de la signalisation qui me gène un peu. Il y 
a tellement de voies, disons "piétonnes", qui n'ont aucune signalisation 
— une très large majorité selon mon ressenti — que je ne sais plus 
vraiment à quoi sert le highway=footway si ce n'est pour signaler qu'il 
y a un panneau. J'avais tendance à l'utiliser pour les aménagement 
dédiés aux piétons (même sans panneau explicite) et effectivement selon 
la pratique (plus ou moins observée ou ressenti) à préciser que les 
cyclistes y sont autorisés.


Ça ne me dérange pas vraiment d'utiliser path mais j'ai l'impression 
qu'on perd un peu de subtilité.


On 17/01/2018 21:00, Romain MEHUT wrote:

Bonsoir,

Je trouve au contraire que c'est le meilleur compromis quand il n'y a 
effectivement pas de signalisation en place.


C'est aussi à mon sens plus compréhensible que d'associer par exemple 
highway=footway + bicycle=yes.


Romain

Le 17 janvier 2018 à 15:19, Charles MILLET > a écrit :


Bonjour,

Je sais qu'il y a une discussion en cours concernant
spécifiquement les pistes cyclables sur les trottoirs et je ne
veux pas faire de doublon. Mais je voulais avoir votre avis sur
une récente modification de la page FR:Bicycle avant de contacter
le contributeur ou de discuter sur la page. Voici la page de
modification pour référence :

https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1547110



La modification concerne cette phrase dans la partie Voies
piétonnes partagées

(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_pi.C3.A9tonnes_partag.C3.A9es

)
:

"En l'absence d'indication de nature de la voie, utiliser
l'attribut highway
=path
 qui
autorise cyclistes et piétons à circuler ensemble"

Même si cette approche est assez commode car elle permet d'éviter
les débats pour savoir si un voie est un footway ou un cycleway,
je la trouve assez catégorique et je ne sais pas elle fait consensus.

-- 
Charles MILLET

charlesmil...@free.fr 


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





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


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

Re: [OSM-talk-fr] Faux positif d'Osmose sur l'identification de la ville

[erwan salomon]

salut,

si je comprend bien voici un cas similaire sans doute plus explicite :
https://www.mapillary.com/map/im/3bJHM08_YPTpmkTlRfyeIw
(avec la traduction bretonne dessous)
ici Fort-Bloqué est déclaré comme « village » dans OSM (avec une limite autour 
: https://www.openstreetmap.org/way/176823228 )
- [ attention village dans le language courant en bretagne désigne quelque 
chose d’encore plus petit, ne jamais dire à un breton qu’il habite dans un 
village il le prendra mal ]
alors que Lacanau de Mios est déclaré comme « hamlet » en tant que node
mais globalement ce sont 2 communes qui font partie d’une agglomération
en tant que tel elles ont un nom et une adresse postale distincte (sinon il y 
aurait des doublon de nom de rue)
mais la gestion administrative se fait par l’agglomération (c’est la mairie de 
Plœmeur qui gère le village de Fort-Bloqué, d’ailleurs les habitant de 
Fort-Bloqué vote pour le maire de Plœmeur)
un quartier c’est en général plus continu avec les quartiers voisins dans le 
langage courant, mais l’agglomération peut en effet diviser sa surface en 
quartier pour en répartir la gestion et procéder à des réunions de quartiers

il y a bien des villes qui ont plusieurs mairies (Paris au moins), ici c’est 
l’inverse

quand à la gestion par Osmose, la je suis incompétent pour te donner des 
conseils

erwan [glyo]
 
> Le 18 janv. 2018 à 00:39, Sébastien Dinot  a écrit :
> 
> Bonsoir,
> 
> Ce soir, en voulant résoudre quelques erreurs qu'Osmose m'attribue parce
> que je suis le dernier contributeur à avoir modifié les objets en
> question, je suis tombé sur la zone suivante :
> 
> http://osmose.openstreetmap.fr/fr/map/#item=2060=18=44.664133=-0.848937=1,2,3=T
> 
> Comme vous le verrez, Osmose signale que la ville de Lacanau-de-Mios est
> inconnue au bataillon. Sur Wikipédia, il est effectivement indiqué que
> Lacanau-de-Mios est un quartier de Mios et non une ville :
> 
> https://fr.wikipedia.org/wiki/Mios
> 
> En outre, sur le site de la ville de Mios, Lacanau-de-Mios est
> explicitement indiqué comme étant un quartier de Mios :
> 
> http://www.villemios.fr/vivre-a-mios/les-conseils-de-quartier/
> 
> J'ai donc contacté le contributeur qui a ajouté ces adresses postales et
> il m'a répondu :
> 
> 1. Qu'il habite là-bas depuis quelques mois (il a eu la courtoisie de ne
>   pas l'exprimer ainsi mais il est donc bien mieux placé que moi pour
>   savoir quelle est l'adresse postale et donc, comment renseigner
>   l'attribut « addr:city »).
> 
> 2. Il m'a transmis un lien vers Google Street View où on voit clairement
>   un panneau de signalisation indiquant l'entrée dans l'agglomération
>   de « Lacanau de Mios » :
> 
>   https://goo.gl/maps/TEhQwaTkUKN2
> 
> Et là, le doute m'envahit. Qu'appelle-t-on une agglomération (zone
> urbaine comptant au moins 2000 habitants dont les habitations sont
> séparées de moins de 200 m) ? Existe-t-il des agglomérations qui ne sont
> pas des villes et des communes ? Il semblerait que oui à la lumière de
> cet exemple. Quid des panneaux de signalisation correspondants ? J'en
> viendrais presque à oublier Osmose qui, pour le coup, me semble faire
> erreur.
> 
> Qu'en pensez-vous ? Comment trancher ?
> 
> Sébastien
> 
> -- 
> Sébastien Dinot, sebastien.di...@free.fr
> http://sebastien.dinot.free.fr/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

[Talk-de] OpenRouteServcice und Autoverlade auf Bahn...

[Lars Schimmer]

Moin!


https://www.openrouteservice.org/directions?n1=46.528635=8.447456=12=46.515406,8.325062,46.598388,8.502045=0=0=en-US=km

Gerade mal geschaut, da jmd. meinte, Google kenne die Autoverlad ned.
Aber das schaut schon komisch aus^^

Die in Slovenien kennt er jedenfalls ned:
https://www.openrouteservice.org/directions?n1=46.214288=13.894615=12=46.281894,13.969674,46.148904,13.757243=0=0=en-US=km

MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723





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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Michal Fabík]

2018-01-18 8:45 GMT+01:00 majka :
> Podle mého jednoznačně loc_name. Ve chvíli, kdy se to objeví na cedulích pak
> přesunout do name

Na cedulích? Jednou mně tady bylo řečeno, že cedule jsou irelevatní a
že směrodatná jsou data ČÚZK.

-- 
Michal Fabík

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