Re: [OSM-talk-fr] Résidence services séniors

[Jean-Claude Repetto]

Le 01/02/2018 à 01:52, Philippe Verdy a écrit :
En quoi c'est si différent des "appart-hôtels" ? ou des colocations ? 



Contrairement aux hôtels, les résidents sont souvent propriétaires de 
leur appartement.


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

Re: [talk-au] Routing through a park that doesn't have actual paths

[Jonathon Rossi]

Thanks Warin,

The Queen Street Mall in Brisbane is exactly that, a pedestrian highway
area and with the tag, however I did read something that the tag has to be
on the way not the relation so probably the reason routing doesn't work
there.
https://www.openstreetmap.org/relation/7781404

I think it makes sense for something that really is a highway, it feels
wrong tagging a park like that though, and iD instantly renders it
different so I suspect it'll introduce rendering problems.

When I get some time I'll try to jump into the GraphHopper discussion to
see if I can understand the problem better and see if a rudimentary
implementation is possible. I can already see how hard it is, how do you
know you can get from a residential road to a park for example.

Thanks again, Jono

On Thu, Feb 1, 2018 at 3:18 PM Warin <61sundow...@gmail.com> wrote:

> On 01-Feb-18 03:35 PM, Jonathon Rossi wrote:
>
> > Exists for areas of concrete too
> Yes true, including car parks which usually don't have footpaths.
>
> > I think if you tag an area as pedestrian, or as steps .. routes will not
> go across them.
> Did you mean to say will or will not go across them?
>
>
> Will NOT go across them. Someone suggest that they may use the way itself
> for routing - so goes around the outside .. that would be helpful at least.
>
> And how would you tag an area as "pedestrian"?
>
> Create a closed way (that is an area), then tag it with
>
> highway=pedestrian
> area=yes  (this last should not be required ... but belt and braces
> approach)
>
> Refer Way: 354759945
> For steps refer Relation: 4645750
>
>
>
> Sounds like the general consensus is that routing is "broken" and we
> continue mapping as you'd expect, and there are no real good workarounds.
>
> Thanks
>
> On Thu, Feb 1, 2018 at 6:48 AM Warin <61sundow...@gmail.com> wrote:
>
>> A 'well known' routing problem.
>>
>> Exists for areas of concrete too ... I think if you tag an area as
>> pedestrian, or as steps .. routes will not go across them.
>> For an area of steps the bottom, top and sides can have ways that are
>> paths ... that gets around the routing issue.
>> In the longer term routes should solve the problem .. they don't see it
>> as an urgent issue as there are not many people using pedestrian routing.
>>
>>
>> On 01-Feb-18 01:45 AM, Jonathon Rossi wrote:
>>
>> It appears that this is a long standing enhancement request for
>> GraphHopper:
>> https://github.com/graphhopper/graphhopper/issues/82
>>
>> On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi 
>> wrote:
>>
>>> To clarify, both Google Maps and Strava routing can't do this either, I
>>> was trying to work out if OSM could do this.
>>>
>>> On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi 
>>> wrote:
>>>
 In the past I've mapped exactly what I've surveyed on the ground in
 local parks, however I've recently been using the OSM routing feature
 rather than from other services and I've discovered it can't route directly
 across a park that is just grass.

 In the following example, I've mapped:
 - the short grass track (eastern side) that council are likely
 inadvertently making each time they bring vehicles through the gate to mow
 the park (the rest of the park boundary has timber bollards),
 - trails that lead from the Greater Glider Conservation Area out into
 the park, the small bit of the "Trail Circuit" in the park isn't actually a
 well defined path it just opens up but it isn't grass and the amount of
 trees keep it path like
 - other well formed paths that lead out to roads


 https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056

 The OSM Wiki states:

 > Ways (highway=path or highway=footway) leading into a park from a
 road, should always be connected to the road for routing purposes. It's
 debatable whether they should connect to the park area with a shared node,
 or cross over the polygon without connecting. TODO discuss
 > (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)

 If a park is just a big grass area (with maybe a few obstacles like a
 playground) then it feels like the responsibility of the routing engine to
 just do this (maybe with an access tag to say it is okay to do so). It
 feels wrong for us mappers to map a "grass" path through the park from each
 entrance that we feel is a main thoroughfare.

 Am I missing something, have others "fixed" this problem elsewhere?

 Jono

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

Re: [talk-au] Routing through a park that doesn't have actual paths

[Warin]

On 01-Feb-18 03:35 PM, Jonathon Rossi wrote:

> Exists for areas of concrete too
Yes true, including car parks which usually don't have footpaths.

> I think if you tag an area as pedestrian, or as steps .. routes will 
not go across them.

Did you mean to say will or will not go across them?


Will NOT go across them. Someone suggest that they may use the way 
itself for routing - so goes around the outside .. that would be helpful 
at least.

And how would you tag an area as "pedestrian"?

Create a closed way (that is an area), then tag it with

highway=pedestrian
area=yes  (this last should not be required ... but belt and braces 
approach)


Refer Way: 354759945
For steps refer Relation: 4645750



Sounds like the general consensus is that routing is "broken" and we 
continue mapping as you'd expect, and there are no real good workarounds.


Thanks

On Thu, Feb 1, 2018 at 6:48 AM Warin <61sundow...@gmail.com 
> wrote:


A 'well known' routing problem.

Exists for areas of concrete too ... I think if you tag an area as
pedestrian, or as steps .. routes will not go across them.
For an area of steps the bottom, top and sides can have ways that
are paths ... that gets around the routing issue.
In the longer term routes should solve the problem .. they don't
see it as an urgent issue as there are not many people using
pedestrian routing.


On 01-Feb-18 01:45 AM, Jonathon Rossi wrote:

It appears that this is a long standing enhancement request for
GraphHopper:
https://github.com/graphhopper/graphhopper/issues/82

On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi
> wrote:

To clarify, both Google Maps and Strava routing can't do this
either, I was trying to work out if OSM could do this.

On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi
> wrote:

In the past I've mapped exactly what I've surveyed on the
ground in local parks, however I've recently been using
the OSM routing feature rather than from other services
and I've discovered it can't route directly across a park
that is just grass.

In the following example, I've mapped:
- the short grass track (eastern side) that council are
likely inadvertently making each time they bring vehicles
through the gate to mow the park (the rest of the park
boundary has timber bollards),
- trails that lead from the Greater Glider Conservation
Area out into the park, the small bit of the "Trail
Circuit" in the park isn't actually a well defined path
it just opens up but it isn't grass and the amount of
trees keep it path like
- other well formed paths that lead out to roads


https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056


The OSM Wiki states:

> Ways (highway=path or highway=footway) leading into a
park from a road, should always be connected to the road
for routing purposes. It's debatable whether they should
connect to the park area with a shared node, or cross
over the polygon without connecting. TODO discuss
> (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)

If a park is just a big grass area (with maybe a few
obstacles like a playground) then it feels like the
responsibility of the routing engine to just do this
(maybe with an access tag to say it is okay to do so). It
feels wrong for us mappers to map a "grass" path through
the park from each entrance that we feel is a main
thoroughfare.

Am I missing something, have others "fixed" this problem
elsewhere?

Jono



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



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



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

[OSM-talk] Mini grant program for Open Data Day

[Jinal Foflia]

Hey everyone,

March 3rd is the Open Data Day. Let us celebrate it by organising or
joining one of the dozens of events around the world.

If you have an event in mind? Apply for a mini-grant to host your own event
in your community [1]. This program is to help local communities share the
benefits of open data, particularly in Open Mapping.

[1] -
https://blog.mapbox.com/apply-for-an-open-data-day-mini-grant-b7dce3ad2d53

Happy mapping,

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

Re: [talk-au] Routing through a park that doesn't have actual paths

[Jonathon Rossi]

> Exists for areas of concrete too
Yes true, including car parks which usually don't have footpaths.

> I think if you tag an area as pedestrian, or as steps .. routes will not
go across them.
Did you mean to say will or will not go across them? And how would you tag
an area as "pedestrian"?

Sounds like the general consensus is that routing is "broken" and we
continue mapping as you'd expect, and there are no real good workarounds.

Thanks

On Thu, Feb 1, 2018 at 6:48 AM Warin <61sundow...@gmail.com> wrote:

> A 'well known' routing problem.
>
> Exists for areas of concrete too ... I think if you tag an area as
> pedestrian, or as steps .. routes will not go across them.
> For an area of steps the bottom, top and sides can have ways that are
> paths ... that gets around the routing issue.
> In the longer term routes should solve the problem .. they don't see it as
> an urgent issue as there are not many people using pedestrian routing.
>
>
> On 01-Feb-18 01:45 AM, Jonathon Rossi wrote:
>
> It appears that this is a long standing enhancement request for
> GraphHopper:
> https://github.com/graphhopper/graphhopper/issues/82
>
> On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi  wrote:
>
>> To clarify, both Google Maps and Strava routing can't do this either, I
>> was trying to work out if OSM could do this.
>>
>> On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi 
>> wrote:
>>
>>> In the past I've mapped exactly what I've surveyed on the ground in
>>> local parks, however I've recently been using the OSM routing feature
>>> rather than from other services and I've discovered it can't route directly
>>> across a park that is just grass.
>>>
>>> In the following example, I've mapped:
>>> - the short grass track (eastern side) that council are likely
>>> inadvertently making each time they bring vehicles through the gate to mow
>>> the park (the rest of the park boundary has timber bollards),
>>> - trails that lead from the Greater Glider Conservation Area out into
>>> the park, the small bit of the "Trail Circuit" in the park isn't actually a
>>> well defined path it just opens up but it isn't grass and the amount of
>>> trees keep it path like
>>> - other well formed paths that lead out to roads
>>>
>>>
>>> https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056
>>>
>>> The OSM Wiki states:
>>>
>>> > Ways (highway=path or highway=footway) leading into a park from a
>>> road, should always be connected to the road for routing purposes. It's
>>> debatable whether they should connect to the park area with a shared node,
>>> or cross over the polygon without connecting. TODO discuss
>>> > (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)
>>>
>>> If a park is just a big grass area (with maybe a few obstacles like a
>>> playground) then it feels like the responsibility of the routing engine to
>>> just do this (maybe with an access tag to say it is okay to do so). It
>>> feels wrong for us mappers to map a "grass" path through the park from each
>>> entrance that we feel is a main thoroughfare.
>>>
>>> Am I missing something, have others "fixed" this problem elsewhere?
>>>
>>> Jono
>>>
>>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-ca] Preferred phone number format

[OSM Volunteer stevea]

>   • There are additionally ~45 phone numbers that use letters instead of 
> digits (eg 1-555-GOT-BEER)
>   • ";" separator is used occasionally to indicate multiple phone 
> numbers.  " ", "," and "/" are also used.
>   • There are random comments in the phone number field (not sure where 
> these really should be?)
>   • Extensions are represented generally by "x" or "ext" or "ext."
>   • There are less than 1000 phone numbers using contact:phone instead of 
> phone, using ~40 unique formats
>   • I did not analyze phone_1 or fax or any other tags.
> I will continue to cleanup phone numbers across the country which are missing 
> the leading +1 and or are not one of the 4 common formats listed above.  My 
> thought is that 
>   • I will leave the phone numbers of 1-555-GOT-BEER type.  
>   • I will use ";" as multiple number separator.  
>   • I will use "x" for extension. 
>   • And I will be happy to cleanup the wonky ones with lots of text in 
> them if there is a direction of where this should move to.  Example for a 
> radio station: "office (###) ###-; on-air studio (###) ###-"
> 
> Feedback welcome.

Those sound largely sane and well thought out to me.  (And I wrote phone number 
parsers for the NANP about 30 years ago, um — wait for it — in HyperTalk!)  The 
GOT-BEER style are best left alone (imo) as smarter parsers eventually figure 
those out.  Yes, ; (semicolon) is a frequent separator in key:value pair value 
lists in OSM data.  Yes, x (choose a case, lower seems better and more common 
than upper) for extensions.  For the radio station/on-air studio stuff I'd make 
the first part of each of these "compound data" be the phone number in one of 
the acceptable formats along with other data, then have extra descriptive text 
added to the rest, even if in a semicolon-separated list.  That's a pretty 
regular set of alphanumerics and with maybe a eight or ten rules, (reasonable 
for a parser extracting machine-dialble phone numbers, if necessary), you're 
either done or at or above 99%, I'd be willing to wager (and I'm not a betting 
type, though I do play poker with friends and online).

Nice job.

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

Re: [Talk-us] tiger name issue in New York

[OSM Volunteer stevea]

I encourage you to edit wiki, Max, it is an important part of OSM-ing, if you 
are one who does, fantastic.  Honest updates or better data, it's easy to write 
and comes naturally to many.  Please, go for It!

Steve

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

Re: [Talk-ca] Preferred phone number format

[Matthew Darwin]

Hi all,

So we get a sense of what phone number formats people are using, I 
pulled all the *phone* and *contact:phone *tags from OSM in Canada.  
The top 10 formats used are:


   8819 phone"+#-###-###-
   4321 phone"###-###-
   4298 phone"+# ###-###-
   3012 phone"+# ### ### 
   2558 phone"+# ### ###-
   2471 phone"(###) ###-
   1087 phone"##
    946 phone"+#-
    680 phone"+# ### ###
    512 phone"+###

So one of the recommended formats is the top one in use.  But there 
are 4 formats in high use which have the leading "+1", but have 
different variants of spaces/hyphens:


   8819 phone"+#-###-###-
   4298 phone"+# ###-###-
   3012 phone"+# ### ### 
   2558 phone"+# ### ###-

Other facts:

 * There are ~400 unique formats (when changing all digits to #) of
   phone and contact:phone
 * There are additionally ~45 phone numbers that use letters instead
   of digits (eg 1-555-GOT-BEER)
 * ";" separator is used occasionally to indicate multiple phone
   numbers.  " ", "," and "/" are also used.
 * There are random comments in the phone number field (not sure
   where these really should be?)
 * Extensions are represented generally by "x" or "ext" or "ext."
 * There are less than 1000 phone numbers using contact:phone instead
   of phone, using ~40 unique formats
 * I did not analyze phone_1 or fax or any other tags.

I will continue to cleanup phone numbers across the country which are 
missing the leading +1 and or are not one of the 4 common formats 
listed above.  My thought is that


 * I will leave the phone numbers of 1-555-GOT-BEER type.
 * I will use ";" as multiple number separator.
 * I will use "x" for extension.
 * And I will be happy to cleanup the wonky ones with lots of text in
   them if there is a direction of where this should move to. 
   Example for a radio station: "office (###) ###-; on-air studio
   (###) ###-"


Feedback welcome.



On 2018-01-28 08:22 PM, Matthew Darwin wrote:

Hi all,

Is there a preferred phone number format we use in Canada?

I noticed a bunch of phone numbers in Ottawa don't follow the 
recommendations in https://wiki.openstreetmap.org/wiki/Key:phone, 
namely:


  * phone=/number/ where the /number/ should be in international
(ITU-T E.164 ) format
  o phone=+  , following
the ITU-T E.123  and the
DIN 5008  pattern
  o (phone=+--, following
the RFC 3966/NANP  pattern)

Is there a preference which of these formats is used?   Can anyone 
run a query and see which is more popular in the country?


The reason I'm asking is that since a bunch of phone numbers leave 
off the +1 (and have other errors), I want to align them to the 
recommended format.   I am wondering if I should have them in the 
format of "+1 999 555 1234" or "+1-999-555-1234". If there is no 
existing preference adopted in OSM Canada, I will use the latter to 
cleanup the non-compliant phone numbers.


Comments?

I am also assuming we prefer "phone" over "contact:phone" as per 
https://wiki.openstreetmap.org/wiki/Key:contact




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

Re: [OSM-talk-fr] Résidence services séniors

[Philippe Verdy]

En quoi c'est si différent des "appart-hôtels" ? ou des colocations ? juste
le critère d'âge (pas forcément très légal si c'est une clause du contrat
d'occupation restreignant l'accès par exemple pour les relations
personnelles ou la famille) et l'accessibilité ?

Cela me semble plus des restrictions d'accès discutables, mais à part ça ce
sont des hôtels avec un "room service" à la demande ou inclus partiellement
dans un forfait.
En cela ça ressemble aussi à bon nombre d'auberges de jeunesse (juste un
critère d'âge différent, le but éducatif n'est pas obligatoire, la
restauration sur place non plus, et il faut sans doute aussi la réserver à
l'avance).
Après on peut taguer les services supplémentaires proposés.
Pour l'accessibilité (handicaps), on a des tags dédiés, je n'en ferait pas
un critère. La résidence elle-même n'assure pas un service médical sur
place (il y a un point de contact médical/infirmier proche, mais il peut
venir de fournisseurs tiers vendant de l'extérieur, également pour les
courses et le ménage ou les transports en taxi à la demande ou une
conciergerie administrative).
"assisted_living" n'est pas garanti d'être inclus, il est disponible mais à
la demande et assez proche pour l'être assez rapidement.
La sécurité c'est avant tout un endroit clos, un barrière commune aux
résidents, avant celle des appartements privés.

Maintenant si l'état leur donne un label "social" avec une référence
sanitaire, cela doit correspondre à des critères définis sur un cahier des
charges minimum et un contrôle de qualité pour les vérifier régulièrement.
Mais là on passe par toute la série des réglementations applicables à
chaque corps de métier assurant un service sur place: il doit y avoir un
certain nombre de labels obligatoires, d'autres optionnels (même si le prix
ou les ressources du résident n'en est pas un et ne permet pas de disposer
d'une aide au logement par exemple). Si un tel label officiel existe, et
émane d'un ministère lié au social ou la santé, alors oui "social" est
approprié indépendamment du prix et des resources.

Le 30 janvier 2018 à 23:57, mav  a écrit :

> Bonsoir,
>
> En pleine grève dans les EHPAD, j'ai une question que je n'arrive pas à
> trancher. Dans ma ville fleurissent les "Résidence services seniors" (
> https://fr.wikipedia.org/wiki/R%C3%A9sidence_services_seniors),
> différentes des classiques maisons de retraite ou EHPAD.
>
> *Les résidences services seniors s’adressent à des personnes âgées
> autonomes, valides et semi-valides de plus de 60 ans, qui désirent vivre en
> appartement ou en maison, tout en profitant de la convivialité et de la
> sécurité assurées par les équipes en place.*
>
> *Elles sont constituées d’appartements individuels (de 1, 2, 3 ou 4
> pièces) et de maisons de plain-pied. Elles ont pour objectif de procurer
> aux résidents une indépendance et de garantir une convivialité dans des
> lieux de vie adaptés et aménagés tels le restaurant, le salon ou l'espace
> forme. Elles sont sécurisées (accueil 7/7 jours, interphone, portails aux
> accès de la résidence…) et adaptées à une clientèle senior (ascenseurs,
> équipement des appartements...). (...)*
>
> Comment les tagger?
>
> Elles ne sont pas hospitalières, et n'ont pas de tarif "social"... mais
> sont tout de même susceptibles de re-créer du lien social pour les
> personnes agées, dans le sens . Peut-on les étiqueter comme maison de
> retraite?
> La moins mauvaise solution me parait être:
> amenity=social_facility + social_facility=assisted_living +
> social_facility:for=senior
> Mais la dimension sociale... bon
>
> Y a-t-il d'autres/ de meilleures solutions/usages? Même de simples avis?!
>
> Merci d'avance de vos retours!
>
> Bonne soirée,
>
> mav
>
>
>
> Pour mémoire:
> * amenity=retirement_home [déprécié au profit de ** amenity
> =social_facility
>  +
> social_facility
> =assisted_living
> 
> + social_facility:for
> =senior]*
>
> *A **[image: Wikipedia-16px.png] Retirement home
> ** is a multi-residence
> home for elderly persons who do not need permanent care. Names and
> definitions vary; in some places in the English speaking world this may be
> called an **old people's home**, a **retirement village**, or a **retirement
> community**. The distinction between this and a **nursing home
> ** is
> primarily that a nursing home implies constantly-available (medical) care
> and a **retirement** home does not. *
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Old Bing/ESRI satellite imagery?

[Albert Pundt]

I concur, thanks for sharing that, Richard! Also reminded me I need to
update my imagery source list in JOSM...

As for me saying my original post was dumb, I didn't mean the very idea of
pointing out the inferior elements of the various imagery sources, I meant
more it appearing to come off as forgetting that, like Ian said, access to
these sources is a privilege and not a right, and I thought it was sounding
like the kind of attitude of entitlement that I'd make fun of in other
contexts...

On Wed, Jan 31, 2018 at 5:24 PM, EthnicFood IsGreat <
ethnicfoodisgr...@gmail.com> wrote:

>
> Message: 1
>> Date: Wed, 31 Jan 2018 03:30:14 -0600 (CST)
>> From: Richard Fairhurst 
>> To: talk-us@openstreetmap.org
>> Subject: Re: [Talk-us] Old Bing/ESRI satellite imagery?
>>
>>
>> The previous ESRI imagery has just been restored to the imagery list (by
>> ESRI, so 100% legit) under the name “Clarity”.
>>
>> Richard
>>
>>
>>
> Great!  I'm glad to hear that.  I use that imagery more than any other.
> Thanks for sharing that news.
>
> Mark
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>



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

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

[Matej Lieskovský]

Co přesně se na editaci zkomplikuje, když budeme podporovat
nedělitelné mezery? To, že na to budeme muset myslet, když budeme psát
dotaz do Overpassu? Podobnými argumenty budeme za chvíli zase všude
mazat diakritiku.

2018-01-31 22:16 GMT+01:00 Martin Mares :
> Ahoj,
>
>> *nikdy* to nebudeme mít 100% správně
>
> nebudeme. Stejně jako nebudeme mít 100% správně nic jiného.
>
> To je myslím lepší přijmout jako fakt, než investovat ohromné množství
> úsilí do něčeho, co bude mít místo 99% úspěšnosti 99.9%.
>
> Chci-li podle dat OSM vytvořit papírovou mapu, vyladím si ji do nejmenších
> detailů. To často znamená ručně předělávat algoritmická rozhodnutí i v daleko
> zásadnějších věcech než dělitelnost mezer: například je často potřeba ručně
> posunout nějakou značku, přemístit či zrušit popisek, nakreslit nějaký objekt
> mimo měřítko atd. Je to spousta práce, ale výsledek stojí za to.
>
> Na druhou stranu, u online mapy zobrazující data, která lidé pořád upravují,
> je taková snaha o dokonalost spíše škodlivá -- nedokonalosti v datech budou
> celkovému dojmu škodit víc než nedokonalosti v prezentaci. Proto je 
> důležitější
> udržet editaci dat co nejjednodušší, i kdyby to stálo o zlomek procenta vyšší
> pravděpodobnost chybné prezentace.
>
> Have a nice fortnight
> --
> Martin `MJ' Mares     http://mj.ucw.cz/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> Some people, when confronted with a problem, think "I know, I'll use XML." 
> Now they have two problems. -- P. J. Eby
>
> ___
> 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-au] Routing through a park that doesn't have actual paths

[Ben Kelley]

I noticed in ridethecity.com (which uses OSM data) that where there is an
area that says bicycle=yes, it will route you around the edges of the area
(as if it was a circular way).

 - Ben.

On 1 February 2018 at 07:47, Warin <61sundow...@gmail.com> wrote:

> A 'well known' routing problem.
>
> Exists for areas of concrete too ... I think if you tag an area as
> pedestrian, or as steps .. routes will not go across them.
> For an area of steps the bottom, top and sides can have ways that are
> paths ... that gets around the routing issue.
> In the longer term routes should solve the problem .. they don't see it as
> an urgent issue as there are not many people using pedestrian routing.
>
>
> On 01-Feb-18 01:45 AM, Jonathon Rossi wrote:
>
> It appears that this is a long standing enhancement request for
> GraphHopper:
> https://github.com/graphhopper/graphhopper/issues/82
>
> On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi  wrote:
>
>> To clarify, both Google Maps and Strava routing can't do this either, I
>> was trying to work out if OSM could do this.
>>
>> On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi 
>> wrote:
>>
>>> In the past I've mapped exactly what I've surveyed on the ground in
>>> local parks, however I've recently been using the OSM routing feature
>>> rather than from other services and I've discovered it can't route directly
>>> across a park that is just grass.
>>>
>>> In the following example, I've mapped:
>>> - the short grass track (eastern side) that council are likely
>>> inadvertently making each time they bring vehicles through the gate to mow
>>> the park (the rest of the park boundary has timber bollards),
>>> - trails that lead from the Greater Glider Conservation Area out into
>>> the park, the small bit of the "Trail Circuit" in the park isn't actually a
>>> well defined path it just opens up but it isn't grass and the amount of
>>> trees keep it path like
>>> - other well formed paths that lead out to roads
>>>
>>> https://www.openstreetmap.org/directions?engine=graphhopper_
>>> foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#
>>> map=18/-27.54200/153.22056
>>>
>>> The OSM Wiki states:
>>>
>>> > Ways (highway=path or highway=footway) leading into a park from a
>>> road, should always be connected to the road for routing purposes. It's
>>> debatable whether they should connect to the park area with a shared node,
>>> or cross over the polygon without connecting. TODO discuss
>>> > (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)
>>>
>>> If a park is just a big grass area (with maybe a few obstacles like a
>>> playground) then it feels like the responsibility of the routing engine to
>>> just do this (maybe with an access tag to say it is okay to do so). It
>>> feels wrong for us mappers to map a "grass" path through the park from each
>>> entrance that we feel is a main thoroughfare.
>>>
>>> Am I missing something, have others "fixed" this problem elsewhere?
>>>
>>> Jono
>>>
>>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>


-- 
Ben Kelley
ben.kel...@gmail.com
http://www.users.on.net/~bhkelley/
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-us] Old Bing/ESRI satellite imagery?

[EthnicFood IsGreat]

Message: 1
Date: Wed, 31 Jan 2018 03:30:14 -0600 (CST)
From: Richard Fairhurst 
To: talk-us@openstreetmap.org
Subject: Re: [Talk-us] Old Bing/ESRI satellite imagery?


The previous ESRI imagery has just been restored to the imagery list (by
ESRI, so 100% legit) under the name “Clarity”.

Richard




Great!  I'm glad to hear that.  I use that imagery more than any other.  
Thanks for sharing that news.


Mark

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

Re: [OSM-talk-fr] Maison du Vélo

[osm . sanspourriel]

Et dans le même genre à Lorient :

https://www.openstreetmap.org/node/5323787819


Le 31/01/2018 à 20:42, Romain MEHUT - romain.me...@gmail.com a écrit :

A Nancy https://www.openstreetmap.org/node/1225759070

Romain

Le 31 janvier 2018 à 13:28, Francescu GAROBY > a écrit :


Pour prendre un exemple que je connais (la Maison du Vélo, à Caen
), le choix a été
fait de sous-tagguer les différents services proposés.

Francescu

Le 31 janvier 2018 à 12:29, marc marc > a écrit :

Bonjour,

Le 31. 01. 18 à 12:04, Simon Réau a écrit :
> Sur Tours : la maison du vélo propose douches, consignes, accueil et
> orientation des touristes, outils et pompe pour réparer son
vélo ainsi
> que la vente de quelques accessoire pour le vélo.
>
> Sur Rennes : Elle propose Point d’accueil pour la location
des vélo
> libre service, différent service proposé par les
associations vélo (vélo
> école, gravure bicycode, atelier d’auto-réparation ...)
espace détente
>
> Comment taguer cela proprement ? actuellement celle de Tours
est taguée
> comme un magasin de vélo
https://www.openstreetmap.org/node/4940263708

> et celle de renne comme une un magasin de location de vélo
associatif

il faut choisir s'il y a une activité principale (à mettre
dans amenity)
avec des "sous-services" (à mettre en sous-tag) ou s'il y a des
activités de même importance (dans ce cas pq pas faire
plusieurs nœuds
dans le même bâtiment) quitte à les regrouper avec une
relation site
(histoire de mettre les coordonnées de contact à un seul endroit).
Par exemple est-ce que l'espace douche est proposé pour les
cyclistes
ou aussi destiné aux voyageurs de passage ?
est-ce que l'info touristique est axé vélo ou c'est aussi info
pédestre?

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





-- 
Francescu


___
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] Nedělitelné mezery v názvech ulic

[Martin Mares]

Ahoj,

> *nikdy* to nebudeme mít 100% správně

nebudeme. Stejně jako nebudeme mít 100% správně nic jiného.

To je myslím lepší přijmout jako fakt, než investovat ohromné množství
úsilí do něčeho, co bude mít místo 99% úspěšnosti 99.9%.

Chci-li podle dat OSM vytvořit papírovou mapu, vyladím si ji do nejmenších
detailů. To často znamená ručně předělávat algoritmická rozhodnutí i v daleko
zásadnějších věcech než dělitelnost mezer: například je často potřeba ručně
posunout nějakou značku, přemístit či zrušit popisek, nakreslit nějaký objekt
mimo měřítko atd. Je to spousta práce, ale výsledek stojí za to.

Na druhou stranu, u online mapy zobrazující data, která lidé pořád upravují,
je taková snaha o dokonalost spíše škodlivá -- nedokonalosti v datech budou
celkovému dojmu škodit víc než nedokonalosti v prezentaci. Proto je důležitější
udržet editaci dat co nejjednodušší, i kdyby to stálo o zlomek procenta vyšší
pravděpodobnost chybné prezentace.

Have a nice fortnight
-- 
Martin `MJ' Mares     http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Some people, when confronted with a problem, think "I know, I'll use XML." Now 
they have two problems. -- P. J. Eby

___
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

[Karel Volný]

Dne středa 31. ledna 2018 20:14:24 CET, Jan Macura napsal(a):
> 2018-01-31 19:58 GMT+01:00 Matej Lieskovský :
> > Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před.
> 
> Aha, to mě nenapadlo.
> Chmno, tak ten by musel mít ten druhý řetězec uložený s Unicode znakem
> U+2164 ;-)

ano, Jindřich [pátý] by takto mohl fungovat

ovšem co takový Xindl [iks]?

- hm, X není předložka ... a kdyby někdo vymyslel ulici na počest Anny [ká]?
(aktuálně se sice na svém webu nazývá s tečkou, ale varianta bez tečky je též 
dosti rozšířená)

přijde mi, že se tu furt vymejšlí rovnák na vohejbák ...

*nikdy* to nebudeme mít 100% správně

chápat různé druhy mezer obecně jako mezeru je triviální úložka, povětšinou 
již vyřešená, i ten blbej grep umí [:space:]

vyvěštit z obecné mezery, jestli tam zrovna patří nsbp (popř. i něco jiného), 
je úložka hodná AI kvalitnější než průměrný maturant z češtiny, a vyřešená 
není

- jistě, co se prvého týče, s jistou chybovostí se můžeme smířit, ale pak 
vzniká otázka, kdyby si někdo chtěl dát tu práci a docílit, aby ten program 
chyby nedělal, tak jaké má možnosti, nemá-li to být vázáno na konkrétní data?

... co mě napadá je seznam vyjímek, ale čeština má tu krásnou vlastnost, že by 
určitě brzy vyplulo něco, co se píše stejně, ale má různé významy, a tudíž ta 
vazba osamoceného písmene může být na obě strany

prozradí nám někdo lepší řešení?

- co se druhého týče, sice lze argumentovat existencí vlny apod., ale, jak zde 
již padlo, problém je, kdo to zaháčkuje do všech rendererů, co kdy vznikly a 
vzniknou?

kdo bude nutit člověka na druhém konci světa implementovat nějakou specialitu 
pro zaprděnou desetimilionovou zemičku, když ani zde mezi zastánci odstranění 
nbsp se nenajde dobrovolník, co by ten preprocesor napsal?

pozn. "renderer" se zde nemusí myslet jen vykreslování mapy, ale obecně 
cokoli, co když si třeba budu chtít adresy tisknout na obálky nebo jánevímco 
se dá nad OSM vymyslet, skutečně to všechno pokryjeme, aby to používalo ten 
(neexistující) preprocesor?

obecně dobré pravidlo "nemapovat pro renderer" se zde dovádí ad absurdum, asi 
jako kdyby někdo řekl "pojďme odstranit u mostů layer, vždyť to se přece dá 
odvodit a existuje na to i pravidlo, renderer musí vědět, že cesta vede nad 
řekou" (hm, ne vždy)

K.


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-au] Routing through a park that doesn't have actual paths

[Warin]

A 'well known' routing problem.

Exists for areas of concrete too ... I think if you tag an area as 
pedestrian, or as steps .. routes will not go across them.
For an area of steps the bottom, top and sides can have ways that are 
paths ... that gets around the routing issue.
In the longer term routes should solve the problem .. they don't see it 
as an urgent issue as there are not many people using pedestrian routing.



On 01-Feb-18 01:45 AM, Jonathon Rossi wrote:
It appears that this is a long standing enhancement request for 
GraphHopper:

https://github.com/graphhopper/graphhopper/issues/82

On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi > wrote:


To clarify, both Google Maps and Strava routing can't do this
either, I was trying to work out if OSM could do this.

On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi > wrote:

In the past I've mapped exactly what I've surveyed on the
ground in local parks, however I've recently been using the
OSM routing feature rather than from other services and I've
discovered it can't route directly across a park that is just
grass.

In the following example, I've mapped:
- the short grass track (eastern side) that council are likely
inadvertently making each time they bring vehicles through the
gate to mow the park (the rest of the park boundary has timber
bollards),
- trails that lead from the Greater Glider Conservation Area
out into the park, the small bit of the "Trail Circuit" in the
park isn't actually a well defined path it just opens up but
it isn't grass and the amount of trees keep it path like
- other well formed paths that lead out to roads


https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056


The OSM Wiki states:

> Ways (highway=path or highway=footway) leading into a park
from a road, should always be connected to the road for
routing purposes. It's debatable whether they should connect
to the park area with a shared node, or cross over the polygon
without connecting. TODO discuss
> (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)

If a park is just a big grass area (with maybe a few obstacles
like a playground) then it feels like the responsibility of
the routing engine to just do this (maybe with an access tag
to say it is okay to do so). It feels wrong for us mappers to
map a "grass" path through the park from each entrance that we
feel is a main thoroughfare.

Am I missing something, have others "fixed" this problem
elsewhere?

Jono



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



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

Re: [OSM-talk-fr] Résidence services séniors

[mav]

Merci de vos réponses à tous les deux!

Bonne soirée,

mav


Le 31/01/2018 à 11:53, Donat ROBAUX a écrit :

Bonjour,

C'est un effet les bons tags.
Si vous avez un doute sur les établissements de santé, sanitaires, 
sociaux, rendez-vous sur le répertoire FINESS 
http://finess.sante.gouv.fr/fininter/jsp/rechercheSimple.jsp


Donat

-- Message transféré --
From: marc marc >
To: "talk-fr@openstreetmap.org "
>
Cc:
Bcc:
Date: Tue, 30 Jan 2018 23:49:04 +
Subject: Re: [OSM-talk-fr] Résidence services séniors
Bonsoir,

Le 30. 01. 18 à 23:57, mav a écrit :
>     /Les résidences services seniors s’adressent à des personnes
âgées
>     autonomes, valides et semi-valides de plus de 60 ans, qui
désirent
>     vivre en appartement ou en maison, tout en profitant de la
>     convivialité et de la sécurité assurées par les équipes en
place.//
> La moins mauvaise solution me parait être:
> amenity=social_facility + social_facility=assisted_living +
> social_facility:for=senior
> Mais la dimension sociale... bon

cela me semble bien.
social c'est aussi "qualité de vie" et sans me prononcer sur
la qualité de l’établissement, ce principe y participe.

> Pour mémoire:*
> amenity=retirement_home [déprécié au profit de
**amenity=social_facility  + social_facility=assisted_living +
social_facility:for=senior

ce n'est pas déprécié.
c'est juste conseillé de basculé sur le nouveau schéma (ce que
j'approuve).

Cordialement,
Marc



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


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

Re: [OSM-talk-be] Overpass turbo exporteren as png

[Jakka]

@glenn on the https://overpass-turbo.eu/master/ it works
but not on the http://overpass-turbo.eu/ strange and what is the 
difference between those two ?






Op 31/01/2018 om 15:44 schreef Glenn Plas:

It works now.  Tested on chrome Version 62.0.3202.94 (Official Build)
(64-bit)

Glenn


On 27-01-18 11:23, Jakka wrote:

Hi,

Trying to export a query map in png do not work.


rendering map data 

Re: [OSM-talk-fr] Vélo et data : nouvelles sources de données et nouveaux usages

[Romain MEHUT]

Bonjour Jean-Christophe,

Autrement dit, tu y seras présent pour rappeler le potentiel d'OSM en la
matière ?

Romain

Le 31 janvier 2018 à 09:15, Jean-Christophe Becquet  a
écrit :

> Bonjour,
>
> Le Congrès de la FUB - vendredi 16 mars 2018 à Lyon
> https://www.fub.fr/sites/fub/files/fub/AG_Congres/programme_je_web.pdf
>
> Avec au programme une session qui pourrait intéresser des contributeurs
> OSM :
>
> Session 2 : Vélo et data : nouvelles sources de données et nouveaux
> usages
>
> Crowdsourcing, traces GPS, signalement : des données au service des
> usagers et des planificateurs.
>
>
> Sur ce même programme, un plan d'accès dont les aspects nouveau,
> crowdsourcé et au service des usagers portent à discussion...
>
> Bonne journée
>
> JCB
> --
> Construisons ensemble vos solutions informatiques - Bonne année 2018 !
> http://www.apitux.org/index.php?2018/01/01/255-voeux-2018
>
> ==APITUX : le choix du logiciel libre==
>
> APITUX - Jean-Christophe Becquet
> BP 32 - 04001 Digne-les-Bains Cedex
> 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
> SIRET : 452 887 441 00031 - APE : 6202A
>
> ===
>
> ___
> 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] Maison du Vélo

[Romain MEHUT]

A Nancy https://www.openstreetmap.org/node/1225759070

Romain

Le 31 janvier 2018 à 13:28, Francescu GAROBY  a écrit :

> Pour prendre un exemple que je connais (la Maison du Vélo, à Caen
> ), le choix a été fait de
> sous-tagguer les différents services proposés.
>
> Francescu
>
> Le 31 janvier 2018 à 12:29, marc marc  a écrit
> :
>
>> Bonjour,
>>
>> Le 31. 01. 18 à 12:04, Simon Réau a écrit :
>> > Sur Tours : la maison du vélo propose douches, consignes, accueil et
>> > orientation des touristes, outils et pompe pour réparer son vélo ainsi
>> > que la vente de quelques accessoire pour le vélo.
>> >
>> > Sur Rennes : Elle propose Point d’accueil pour la location des vélo
>> > libre service, différent service proposé par les associations vélo (vélo
>> > école, gravure bicycode, atelier d’auto-réparation ...) espace détente
>> >
>> > Comment taguer cela proprement ? actuellement celle de Tours est taguée
>> > comme un magasin de vélo https://www.openstreetmap.org/node/4940263708
>> > et celle de renne comme une un magasin de location de vélo associatif
>>
>> il faut choisir s'il y a une activité principale (à mettre dans amenity)
>> avec des "sous-services" (à mettre en sous-tag) ou s'il y a des
>> activités de même importance (dans ce cas pq pas faire plusieurs nœuds
>> dans le même bâtiment) quitte à les regrouper avec une relation site
>> (histoire de mettre les coordonnées de contact à un seul endroit).
>> Par exemple est-ce que l'espace douche est proposé pour les cyclistes
>> ou aussi destiné aux voyageurs de passage ?
>> est-ce que l'info touristique est axé vélo ou c'est aussi info pédestre?
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Francescu
>
> ___
> 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

[Jan Macura]

2018-01-31 19:58 GMT+01:00 Matej Lieskovský :

> Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před.
>

Aha, to mě nenapadlo.
Chmno, tak ten by musel mít ten druhý řetězec uložený s Unicode znakem
U+2164 ;-)

H.
___
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

[Matej Lieskovský]

Vždyť jo. V prvním případě má být nbsp za "V.", v druhém před.

2018-01-31 19:20 GMT+01:00 Jan Macura :
> 2018-01-31 14:56 GMT+01:00 Matej Lieskovský :
>>
>> Opravdu chci vidět preprocesor, který zvládne rozpoznat "Dům V. Hálka"
>> od "Jindřich V. Sálský" (fiktivní příklady).
>
>
> V předmětu tohoto vlákna stále ještě stojí "Nedělitelné mezery v názvech
> ulic". Nic víc, nic míň. A na to jsem taky reagoval.
>
> 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: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Macura]

2018-01-31 14:56 GMT+01:00 Matej Lieskovský :

> Opravdu chci vidět preprocesor, který zvládne rozpoznat "Dům V. Hálka"
> od "Jindřich V. Sálský" (fiktivní příklady).
>

V předmětu tohoto vlákna stále ještě stojí "Nedělitelné mezery v názvech
ulic". Nic víc, nic míň. A na to jsem taky reagoval.

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

Re: [Talk-us] tiger name issue in New York

[Kevin Kenny]

On Wed, Jan 31, 2018 at 9:54 AM, Max Erickson  wrote:

> I took note of it just seeing the name in parking lots in towns and on
> obvious driveways. It seems armchair cleanup would be able to address
> those.
>
> Maybe I will get over my reticence to edit the wiki and make a page
> for listing these sorts of "structural" issues with Tiger data. Could
> also list things like counties with *extremely* poor geometry or high
> numbers of service roads imported as residential.
>

OK, yeah, obvious driveways are a different thing. When I saw the
original message, I had in mind more things like:

Cheney Pond Road:
https://www.openstreetmap.org/way/20078367
(need to verify that this is passable - I have reason to believe that it
is, at least for a 4WD)

Cheney Pond-Irishtown snowmobile trail:
https://www.openstreetmap.org/way/20078250
This one inexplicably stops at the ford at the ruined dam on Lester
Flow. It's in fact continuous with Cheney Pond Road in Irishtown:
https://www.openstreetmap.org/way/20088051
which is mislabeled; only the short section up to Shevlin
Road is called Byrnes Road. I have it on good authority that
this road is gated at both ends, but there are still a handful of
landowners who have inholdings at the edge of the Hoffman
Notch Wilderness, have the keys to the gate, and access
their holdings by 4WD or ATV.

Mud Mountain Horse Trail:
https://www.openstreetmap.org/way/2008

(Mostly part of) the abandoned Grass[e] River Railroad [1915-1957]
(usable as a MTB trail but you have to be careful of the ties):
https://www.openstreetmap.org/way/8750962

About half part of the Grass[e] River right-of-way and about half
I-don't-know-what. https://www.openstreetmap.org/way/8752087

These facts are from second-hand local knowledge and non-free
published sources, so I don't feel comfortable putting anything into
OSM until and unless I survey that area. (Which I may do in 3-4
years, as part of a different project entirely.)

I suppose that if someone wanted to remove the names 'Adirondack
Park' and 'Adirondack Park Preserve' from all the roads in that area,
leaving them nameless, I wouldn't make much of a fuss. The
name doesn't add useful information. I simply haven't bothered
on ways that I haven't surveyed, because of all the other issues.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] tiger name issue in New York

[Max Erickson]

I took note of it just seeing the name in parking lots in towns and on
obvious driveways. It seems armchair cleanup would be able to address
those.

Maybe I will get over my reticence to edit the wiki and make a page
for listing these sorts of "structural" issues with Tiger data. Could
also list things like counties with *extremely* poor geometry or high
numbers of service roads imported as residential.


Max

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

Re: [talk-au] Routing through a park that doesn't have actual paths

[Jonathon Rossi]

It appears that this is a long standing enhancement request for GraphHopper:
https://github.com/graphhopper/graphhopper/issues/82

On Thu, Feb 1, 2018 at 12:17 AM Jonathon Rossi  wrote:

> To clarify, both Google Maps and Strava routing can't do this either, I
> was trying to work out if OSM could do this.
>
> On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi  wrote:
>
>> In the past I've mapped exactly what I've surveyed on the ground in local
>> parks, however I've recently been using the OSM routing feature rather than
>> from other services and I've discovered it can't route directly across a
>> park that is just grass.
>>
>> In the following example, I've mapped:
>> - the short grass track (eastern side) that council are likely
>> inadvertently making each time they bring vehicles through the gate to mow
>> the park (the rest of the park boundary has timber bollards),
>> - trails that lead from the Greater Glider Conservation Area out into the
>> park, the small bit of the "Trail Circuit" in the park isn't actually a
>> well defined path it just opens up but it isn't grass and the amount of
>> trees keep it path like
>> - other well formed paths that lead out to roads
>>
>>
>> https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056
>>
>> The OSM Wiki states:
>>
>> > Ways (highway=path or highway=footway) leading into a park from a road,
>> should always be connected to the road for routing purposes. It's debatable
>> whether they should connect to the park area with a shared node, or cross
>> over the polygon without connecting. TODO discuss
>> > (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)
>>
>> If a park is just a big grass area (with maybe a few obstacles like a
>> playground) then it feels like the responsibility of the routing engine to
>> just do this (maybe with an access tag to say it is okay to do so). It
>> feels wrong for us mappers to map a "grass" path through the park from each
>> entrance that we feel is a main thoroughfare.
>>
>> Am I missing something, have others "fixed" this problem elsewhere?
>>
>> Jono
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-be] Overpass turbo exporteren as png

[Glenn Plas]

It works now.  Tested on chrome Version 62.0.3202.94 (Official Build)
(64-bit)

Glenn


On 27-01-18 11:23, Jakka wrote:
> Hi,
>
> Trying to export a query map in png do not work.
>
>
>     rendering map data      rendering map tiles
>     prepare map
>
>
> Is this a known issue ?
>
>
> ___
> 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

[OSM-talk] OpenStreetMap Carto release v4.7.1

[Daniel Koć]

|Dear all, Today, v4.7.1 of the openstreetmap-carto stylesheet (the 
default stylesheet on the OSM website) has been released. Once changes 
are deployed on the openstreetmap.org it will take couple of days before 
all tiles show the new rendering. This is a bugfix release, the only 
change is a code fixing this rendering problem: 
https://github.com/gravitystorm/openstreetmap-carto/issues/3043 Thanks 
to all the contributors for this release. For a full list of commits, 
see 
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.7.0...v4.7.1 
As always, we welcome any bug reports at 
https://github.com/gravitystorm/openstreetmap-carto/issues|


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


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

Re: [Talk-us] tiger name issue in New York

[Kevin Kenny]

On Wed, Jan 31, 2018 at 8:14 AM, Max Erickson  wrote:

> About 1600 highways named "Adirondack Park" and another 300 named
> "Adirondack Park Preserve". Mostly service drives that are in
> Adirondack Park, but it seems unlikely that they are all actually
> named that way.
>
> http://overpass-turbo.eu/s/vDk


The locals are aware of this. It's worse than you think.

I've fixed some, but  it's slow going. A good many of those roads are
tracks or less, and few are signed. (They do have names, but you
have to find them in published sources or ask a local.)

Most of the ones that are entirely
within the park have been closed to motor vehicles since the 1970s.
They're mapped so inaccurately in many cases that the whole data
set has a hallucinatory quality to it.

There's a New York State data set that's a better source on the names,
but I've not been able to secure permission to use it. Its data
quality is also pretty poor. The agency that maintains it is
chronically underfunded.

For all these reasons, I tend to think that repairs aren't adding much
value unless they're backed up by literal boots on the ground.
I haven't nearly as much time to travel as I'd like.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-au] Routing through a park that doesn't have actual paths

[Jonathon Rossi]

To clarify, both Google Maps and Strava routing can't do this either, I was
trying to work out if OSM could do this.

On Thu, Feb 1, 2018 at 12:10 AM Jonathon Rossi  wrote:

> In the past I've mapped exactly what I've surveyed on the ground in local
> parks, however I've recently been using the OSM routing feature rather than
> from other services and I've discovered it can't route directly across a
> park that is just grass.
>
> In the following example, I've mapped:
> - the short grass track (eastern side) that council are likely
> inadvertently making each time they bring vehicles through the gate to mow
> the park (the rest of the park boundary has timber bollards),
> - trails that lead from the Greater Glider Conservation Area out into the
> park, the small bit of the "Trail Circuit" in the park isn't actually a
> well defined path it just opens up but it isn't grass and the amount of
> trees keep it path like
> - other well formed paths that lead out to roads
>
>
> https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056
>
> The OSM Wiki states:
>
> > Ways (highway=path or highway=footway) leading into a park from a road,
> should always be connected to the road for routing purposes. It's debatable
> whether they should connect to the park area with a shared node, or cross
> over the polygon without connecting. TODO discuss
> > (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)
>
> If a park is just a big grass area (with maybe a few obstacles like a
> playground) then it feels like the responsibility of the routing engine to
> just do this (maybe with an access tag to say it is okay to do so). It
> feels wrong for us mappers to map a "grass" path through the park from each
> entrance that we feel is a main thoroughfare.
>
> Am I missing something, have others "fixed" this problem elsewhere?
>
> Jono
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-us] tiger name issue in New York

[Dave Swarthout]

I have noticed that as well. Aggravating, isn't it? I've not seen a sign
with "Adirondack Park" on any road I've driven there. I'm sure Kevin Kenny
will have some knowledge to contribute.

Cheers

Dave

On Wed, Jan 31, 2018 at 8:14 PM, Max Erickson  wrote:

> About 1600 highways named "Adirondack Park" and another 300 named
> "Adirondack Park Preserve". Mostly service drives that are in
> Adirondack Park, but it seems unlikely that they are all actually
> named that way.
>
> http://overpass-turbo.eu/s/vDk
>
>
> Max
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[talk-au] Routing through a park that doesn't have actual paths

[Jonathon Rossi]

In the past I've mapped exactly what I've surveyed on the ground in local
parks, however I've recently been using the OSM routing feature rather than
from other services and I've discovered it can't route directly across a
park that is just grass.

In the following example, I've mapped:
- the short grass track (eastern side) that council are likely
inadvertently making each time they bring vehicles through the gate to mow
the park (the rest of the park boundary has timber bollards),
- trails that lead from the Greater Glider Conservation Area out into the
park, the small bit of the "Trail Circuit" in the park isn't actually a
well defined path it just opens up but it isn't grass and the amount of
trees keep it path like
- other well formed paths that lead out to roads

https://www.openstreetmap.org/directions?engine=graphhopper_foot=-27.54259%2C153.22173%3B-27.54227%2C153.21904#map=18/-27.54200/153.22056

The OSM Wiki states:

> Ways (highway=path or highway=footway) leading into a park from a road,
should always be connected to the road for routing purposes. It's debatable
whether they should connect to the park area with a shared node, or cross
over the polygon without connecting. TODO discuss
> (https://wiki.openstreetmap.org/wiki/Tag:leisure=park)

If a park is just a big grass area (with maybe a few obstacles like a
playground) then it feels like the responsibility of the routing engine to
just do this (maybe with an access tag to say it is okay to do so). It
feels wrong for us mappers to map a "grass" path through the park from each
entrance that we feel is a main thoroughfare.

Am I missing something, have others "fixed" this problem elsewhere?

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

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

[Matej Lieskovský]

Opravdu chci vidět preprocesor, který zvládne rozpoznat "Dům V. Hálka"
od "Jindřich V. Sálský" (fiktivní příklady).


2018-01-28 17:16 GMT+01:00 Jan Macura :
> Ahoj,
>
> 2018-01-27 19:36 GMT+01:00 Martin Mares :
>>
>> Proto by mi dávalo daleko lepší smysl ukládat toho do primárních dat
>> co nejméně a napsat preprocesor, který bude umět tyto věci odvozovat
>> a jehož výstup bude moci využít libovolný renderer.
>
>
>  To se mi zatím zdá jako nejrozumnější argument v této diskusi.
> A neexistuje třeba už nějaký takový preprocesor? Vybavuji si článek, ve
> kterém nějaký tým řešil, jak lépe zalamovat popisky v mapě (dokonce bych
> řekl, že to bylo pro OSM Carto), tak aby to vypadalo hezky. To s naším
> problémem jednopísmených předložek na koncích řádek docela souvisí.
>
> 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: [Talk-gb-westmidlands] February Meeting

[Brian Prangle]

Let's go back to The BUll

On Mon, Jan 29, 2018 at 8:38 PM, Rob Nickerson 
wrote:

> I'll be there this month:-)
>
> A look back at previous emails threw up the following list:
>
> - The gunmakers arms. Just round the corner from the bull. (seems to have
> it's own micro brewery)
>
> - Queen's Arms, Newhall St
>
> - The Shakespeare, Summer Row
>
> - The Wellington (no event on Wednesday / live folk music on Thursday). 
> Bennetts
> Hill
>
> - The Lost and Found.. Bennetts Hill
> We tried The Wellington (good but no food, although they do allow
> takeaway) and the Gunmakers Arms (struggled with food and was just one
> option - would need to arrange in advance).
>
> I'd be up for anything including a return to The Bull.
>
> Anyone want to pick one?
>
> Regards,
> Rob
>
> *Rob*
>
> On 29 January 2018 at 18:50, Brian Prangle  wrote:
>
>> Hi everyone
>>
>> First Thursday is this week so see you there. Do we meet at the regular
>> pub or is there a new venue?
>>
>> Regards
>>
>> Brian
>>
>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
>>
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-us] tiger name issue in New York

[Max Erickson]

About 1600 highways named "Adirondack Park" and another 300 named
"Adirondack Park Preserve". Mostly service drives that are in
Adirondack Park, but it seems unlikely that they are all actually
named that way.

http://overpass-turbo.eu/s/vDk


Max

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

Re: [Talk-GB] OSM Conflator

[Rob Nickerson]

Many thanks for this. I shall add some clarifying remarks to the post.

Best,
Rob

On 31 Jan 2018 8:06 a.m., "Ilya Zverev"  wrote:

> I wrote up part 1 of my experience with OSM Conflator and the Community
Validation tool. This first part focuses on OSM Conflator explaining what
it does and the main components of it.
>
> http://www.mappa-mercia.org/2018/01/osm-conflator.html

Thank you Rob, I enjoyed reading your post. I hope it drives more people to
do their POI imports with the Conflator.

I have a single comment about "it assumes the third party data is correct
and more up to date than any OSM data it is replacing". The third party
data does indeed need to be correct, otherwise we should not import it into
OSM. But in the profile "master_tags" property you choose a range of
attributes that override these mapped by OSM members. For example, if you
consider postcodes in OSM better than in the third party data, you don't
add the "addr:postcode" to that list.

Also, nodes and areas are almost never moved, never for the initial import.
Locations from OSM are considered to be the most precise. Of course, with
the Community Validation tool mappers can adjust some locations to match
these from a third party dataset.

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

Re: [OSM-talk-fr] Maison du Vélo

[Francescu GAROBY]

Pour prendre un exemple que je connais (la Maison du Vélo, à Caen
), le choix a été fait de
sous-tagguer les différents services proposés.

Francescu

Le 31 janvier 2018 à 12:29, marc marc  a écrit :

> Bonjour,
>
> Le 31. 01. 18 à 12:04, Simon Réau a écrit :
> > Sur Tours : la maison du vélo propose douches, consignes, accueil et
> > orientation des touristes, outils et pompe pour réparer son vélo ainsi
> > que la vente de quelques accessoire pour le vélo.
> >
> > Sur Rennes : Elle propose Point d’accueil pour la location des vélo
> > libre service, différent service proposé par les associations vélo (vélo
> > école, gravure bicycode, atelier d’auto-réparation ...) espace détente
> >
> > Comment taguer cela proprement ? actuellement celle de Tours est taguée
> > comme un magasin de vélo https://www.openstreetmap.org/node/4940263708
> > et celle de renne comme une un magasin de location de vélo associatif
>
> il faut choisir s'il y a une activité principale (à mettre dans amenity)
> avec des "sous-services" (à mettre en sous-tag) ou s'il y a des
> activités de même importance (dans ce cas pq pas faire plusieurs nœuds
> dans le même bâtiment) quitte à les regrouper avec une relation site
> (histoire de mettre les coordonnées de contact à un seul endroit).
> Par exemple est-ce que l'espace douche est proposé pour les cyclistes
> ou aussi destiné aux voyageurs de passage ?
> est-ce que l'info touristique est axé vélo ou c'est aussi info pédestre?
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Maison du Vélo

[marc marc]

Bonjour,

Le 31. 01. 18 à 12:04, Simon Réau a écrit :
> Sur Tours : la maison du vélo propose douches, consignes, accueil et 
> orientation des touristes, outils et pompe pour réparer son vélo ainsi 
> que la vente de quelques accessoire pour le vélo.
> 
> Sur Rennes : Elle propose Point d’accueil pour la location des vélo 
> libre service, différent service proposé par les associations vélo (vélo 
> école, gravure bicycode, atelier d’auto-réparation ...) espace détente
> 
> Comment taguer cela proprement ? actuellement celle de Tours est taguée 
> comme un magasin de vélo https://www.openstreetmap.org/node/4940263708 
> et celle de renne comme une un magasin de location de vélo associatif

il faut choisir s'il y a une activité principale (à mettre dans amenity) 
avec des "sous-services" (à mettre en sous-tag) ou s'il y a des 
activités de même importance (dans ce cas pq pas faire plusieurs nœuds 
dans le même bâtiment) quitte à les regrouper avec une relation site 
(histoire de mettre les coordonnées de contact à un seul endroit).
Par exemple est-ce que l'espace douche est proposé pour les cyclistes
ou aussi destiné aux voyageurs de passage ?
est-ce que l'info touristique est axé vélo ou c'est aussi info pédestre?

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Will Phillips]

On 31/01/2018 09:07, Mark Goodge wrote:

Which is the more correct usage here? Do we

a) tag the dependent street as the addr:street, and the main street as 
addr:parentstreet, or should we


b) (following Royal Mail practice as found in the PAF), tag the 
dependent street as a addr:substreet and the main street as addr:street?


My personal preference would be the latter, it's not only consistent 
with official addressing practice but it's also how most people 
perceive these kind of addresses as well. But, on the other hand, most 
map editors are likely to use addr:street for the dependent street, 
simply because the editor UI doesn't make it obvious that 
addr:substreet is a possibility. So it might be simpler to fix these 
by adding addr:parentstreet as necessary rather than trying to get 
everything pedantically correct.


Mark


I favour using addr:parentstreet rather than addr:substreet for the 
following reasons:


1. The majority of OSM data users and tools/services using OSM data 
don't know that either addr:substreet or addr:parentstreet exist. They 
will recognise addr:housenumber and addr:street. Therefore I think the 
most important part of the address should use these tags, which is 
usually the dependent street and number. If someone is searching for an 
address, I think this is usually the part they will enter.


2. When mapping addresses I consider the addr:housenumber and 
addr:street to go together. Otherwise it is ambiguous, because there is 
no way of knowing whether the number relates to the dependent or parent 
street. This can get very confusing because the same numbers will often 
be used for addresses along the main part of the street and again on any 
subsidiary parts. If we wanted to use addr:substreet without any 
ambiguity, we would need something like addr:substreetnumber as well.


3. Using addr:substreet is just more confusing. New mappers aren't going 
to understand it. If a street has its own name and is separately 
numbered, it's intuitive to put this into the widely recognised 
addr:housenumber and addr:street tags. I know from surveying a lot of 
addresses that is difficult to guess whether Royal Mail considers a 
street to be dependent or not: such streets often don't look any 
different from other nearby streets that aren't. It's not something 
mappers should have to worry about in the majority of cases.



Just to add, I don't think addr:parentstreet it always the best 
approach. Where a 'dependent street' is say a block of flats without a 
physically separate street, using addr:housename and addr:flats is often 
simpler.


Regards,
Will

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

Re: [OSM-talk-fr] Saisie d'informations liées à la pêche

[marc marc]

Bonjour,

Le 31. 01. 18 à 11:21, Nicolas Moyroud a écrit :
> il voudrait indiquer les zones en nokill (on 
> doit rejeter le poisson après l'avoir pêché). Ce n'est pas documenté 
> dans le wiki mais je pense qu'une bonne solution serait d'utiliser 
> fishing=nokill.

j'ai trouvé 4 malheureux no_kill
https://taginfo.openstreetmap.org/keys/fishing#values
Probablement à combiner avec leisure=fishing :)

> les catégories officielles de la fédération de pêche en France.

attention aux problèmes de licence.
si quelque chose l'indique sur le terrain, c'est facile de les ajouter.
s'il importe les infos de la fédé, faudra chercher la licence.

> deux catégories : la première correspond aux zones de présence des salmonidés 
> (têtes de bassin), la deuxième aux zones sans salmonidé.
> Ma proposition serait fishing:FR:category=1 ou 
> fishing:FR:category=2. Qu'est que vous en pensez ?

j'ai trouvé qlq centaines de tag, tous en France
https://taginfo.openstreetmap.org/keys/fishing_water_type
https://taginfo.openstreetmap.fr/keys/fishing_water_type#map
le nom du tag n'est pas terrible mais cela vaudrait la peine
de contacter celui/ceux qui les ont mis (lien overpass puis histo).
Concernant ":FR", mon avis habituel est de les fuir autant
que possible. je ne vois pas ce qu'apporte la possibilité
d'ajouter un :FR pour dire que la rivière en France
a une info française. Je trouve que cette fragmentation nuit
à l'utilisation des données au niveau applicatif.
Concernant la catégorie, au risque de dire une bêtise car ce n'est
pas mon domaine, le classement ne concerne que les salmonidés ?
donc pas les brochet et les sandres par exemple ?

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

[Talk-it] Sabbioneta progetto Cerchio d'Acqua e richiesta supporto per possibile import

[Giorgio Limonta]

Buongiorno lista,
relativamente alla procedura di import connessa al progetto in oggetto, di cui 
alle mie precedenti mail di ottobre, vi aggiorno sul fatto che il Comune di 
Sabbioneta ci ha autorizzato formalmente ad utilizzare il materiale 
cartografico proveniente dall'aerofotogrammetrico per la diffusione tramite OSM 
come meglio descritto e documentato nella pagina wiki dedicata [1] per la quale 
ringrazio ancora Ale_Zena per il prezioso supporto e la consueta disponibilità. 
Ho pertanto estrapolato dall'aerofogrammetrico comunale le geometrie 
dell'edificato della parte della città murata e di un buffer esterno di circa 
1km per un totale di 1130 nuove feature per le quali ho verificato puntualmente 
la correttezza topologica e la relativa altezza utile. Per gli altri edifici 
dell'immenso territorio comunale di Sabbioneta procederò con un import 
successivo perché al momento ho la necessità di migliorare la mappa di base 
dell'area UNESCO per caricare anche le altre informazioni connesse al progetto, 
per le quali tra l'altro realizzeremo delle riprese aree con un drone per 
produrre materiali informativi da diffondere (anche tramite i canali Wikimedia) 
per migliorare la conoscenza e la mappatura del sito (se riusciamo vorremmo 
realizzare delle immagini zenitali dell'area da diffondere anche tramite un 
servizio WMS, ma questo dipenderà molto dalla qualità delle riprese).
A questo link [2] trovate il file .osm per chiunque volesse verificare la 
correttezza delle feature e dei relativi tag, ho inoltre creato la pagina wiki 
dell'import [3] cercando di evidenziare (spero) chiaramente i passaggi 
effettuati.
Se non c'è nulla di problematico procederei all'import al più presto ovviamente 
integrando le informazioni già presenti su OSM.
Grazie in anticipo
Buona giornata
Giorgio

[1] https://wiki.openstreetmap.org/wiki/Lombardia/MN/Sabbioneta[2] 
https://drive.google.com/open?id=1fTEcxMFFP_iUlkZxFWi8QAKWLXDBCFhN
[3] https://wiki.openstreetmap.org/wiki/Sabbioneta



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

[OSM-talk-fr] Maison du Vélo

[Simon Réau]

Bonjour,

J'ai un souci pour taguer les maison du vélo.

J'ai deux exemples.
Sur Tours : la maison du vélo propose douches, consignes, accueil et
orientation des touristes, outils et pompe pour réparer son vélo ainsi que
la vente de quelques accessoire pour le vélo.

Sur Rennes : Elle propose Point d’accueil pour la location des vélo libre
service, différent service proposé par les associations vélo (vélo école,
gravure bicycode, atelier d’auto-réparation ...) espace détente

Comment taguer cela proprement ? actuellement celle de Tours est taguée
comme un magasin de vélo https://www.openstreetmap.org/node/4940263708 et
celle de renne comme une un magasin de location de vélo associatif

Cordialement

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

Re: [OSM-talk-fr] Résidence services séniors

[Donat ROBAUX]

Bonjour,

C'est un effet les bons tags.
Si vous avez un doute sur les établissements de santé, sanitaires, sociaux,
rendez-vous sur le répertoire FINESS
http://finess.sante.gouv.fr/fininter/jsp/rechercheSimple.jsp

Donat


> -- Message transféré --
> From: marc marc 
> To: "talk-fr@openstreetmap.org" 
> Cc:
> Bcc:
> Date: Tue, 30 Jan 2018 23:49:04 +
> Subject: Re: [OSM-talk-fr] Résidence services séniors
> Bonsoir,
>
> Le 30. 01. 18 à 23:57, mav a écrit :
> > /Les résidences services seniors s’adressent à des personnes âgées
> > autonomes, valides et semi-valides de plus de 60 ans, qui désirent
> > vivre en appartement ou en maison, tout en profitant de la
> > convivialité et de la sécurité assurées par les équipes en place.//
> > La moins mauvaise solution me parait être:
> > amenity=social_facility + social_facility=assisted_living +
> > social_facility:for=senior
> > Mais la dimension sociale... bon
>
> cela me semble bien.
> social c'est aussi "qualité de vie" et sans me prononcer sur
> la qualité de l’établissement, ce principe y participe.
>
> > Pour mémoire:*
> > amenity=retirement_home [déprécié au profit de
> **amenity=social_facility  + social_facility=assisted_living +
> social_facility:for=senior
>
> ce n'est pas déprécié.
> c'est juste conseillé de basculé sur le nouveau schéma (ce que j'approuve).
>
> Cordialement,
> Marc
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Saisie d'informations liées à la pêche

[Nicolas Moyroud]

Salut à tous,

Un ami pêcheur qui contribue un peu à OSM m'a posé des questions 
concernant le tagging d'infos liées à la pêche en France pour les lacs 
et les rivières. J'ai quelques propositions à lui faire, mais je 
voudrais avoir l'avis de spécialistes de la question si il y en a par ici.


Pour les zones en réserve (pêche interdite) le wiki indique clairement 
fishing=no. Par contre, il voudrait indiquer les zones en nokill (on 
doit rejeter le poisson après l'avoir pêché). Ce n'est pas documenté 
dans le wiki mais je pense qu'une bonne solution serait d'utiliser 
fishing=nokill.


Il me posait également la question pour les zones accessibles aux 
handicapés. Là je pense que la question ne se pose pas, c'est comme pour 
les accessibilité commerces ou les places de parking avec wheelchair=yes.


Enfin et surtout, il souhaite saisir dans OSM les catégories officielles 
de la fédération de pêche en France. Il m'a expliqué qu'il y avait deux 
catégories : la première correspond aux zones de présence des salmonidés 
(têtes de bassin), la deuxième aux zones sans salmonidé. Pour cette 
problématique je n'ai trouvé aucune info, je pense qu'il faudrait 
inventer un nouveau tag à ajouter sur les tronçons de rivières ou les 
lacs. Ma proposition serait fishing:FR:category=1 ou 
fishing:FR:category=2. Qu'est que vous en pensez ?


Merci pour votre aide.

Nicolas


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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 31/01/18 09:07, Mark Goodge wrote:

On 27/01/2018 20:09, Robert Whittaker (OSM lists) wrote:


Secondly, some addresses contain two street names, a main
street and a so-called "dependent street". Apart from the historic
anomalies, a single postcode should only cover one main street, but
can include more than one dependent street.


These are actually quite common, and having had a look at the error list 
for my local area nearly all of them are due to this - the address is on 
  secondary street accessed from the main street with which it shares a 
postcode. Here's one, for example:


https://www.openstreetmap.org/way/304095650


(The tool will not see the
dependent streets as different if both streets are tagged, either as
addr:substreet and addr:street or as addr:street and
addr:parentstreet.) 


Which is the more correct usage here? Do we

a) tag the dependent street as the addr:street, and the main street as 
addr:parentstreet, or should we


b) (following Royal Mail practice as found in the PAF), tag the 
dependent street as a addr:substreet and the main street as addr:street?


My personal preference would be the latter, it's not only consistent 
with official addressing practice but it's also how most people perceive 
these kind of addresses as well. But, on the other hand, most map 
editors are likely to use addr:street for the dependent street, simply 
because the editor UI doesn't make it obvious that addr:substreet is a 
possibility. So it might be simpler to fix these by adding 
addr:parentstreet as necessary rather than trying to get everything 
pedantically correct.


I've the same problem on a number of cases and certainly 
addr:parentstreet is just wrong ... the sub street is actually part of 
the house detail rather than the street, so similar to 'Flat 1 Block of 
Flats' ' Street' but this still leaves the 'addr:street' or 
'postal_code' question for the tag on the primary street. Having SOME of 
these tagged 'addr:parentstreet' is simply wrong ...


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

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

Re: [Talk-us] Old Bing/ESRI satellite imagery?

[Richard Fairhurst]

The previous ESRI imagery has just been restored to the imagery list (by
ESRI, so 100% legit) under the name “Clarity”. 

Richard 



--
Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Mark Goodge]

On 27/01/2018 20:09, Robert Whittaker (OSM lists) wrote:


Secondly, some addresses contain two street names, a main
street and a so-called "dependent street". Apart from the historic
anomalies, a single postcode should only cover one main street, but
can include more than one dependent street.


These are actually quite common, and having had a look at the error list 
for my local area nearly all of them are due to this - the address is on 
 secondary street accessed from the main street with which it shares a 
postcode. Here's one, for example:


https://www.openstreetmap.org/way/304095650


(The tool will not see the
dependent streets as different if both streets are tagged, either as
addr:substreet and addr:street or as addr:street and
addr:parentstreet.) 


Which is the more correct usage here? Do we

a) tag the dependent street as the addr:street, and the main street as 
addr:parentstreet, or should we


b) (following Royal Mail practice as found in the PAF), tag the 
dependent street as a addr:substreet and the main street as addr:street?


My personal preference would be the latter, it's not only consistent 
with official addressing practice but it's also how most people perceive 
these kind of addresses as well. But, on the other hand, most map 
editors are likely to use addr:street for the dependent street, simply 
because the editor UI doesn't make it obvious that addr:substreet is a 
possibility. So it might be simpler to fix these by adding 
addr:parentstreet as necessary rather than trying to get everything 
pedantically correct.


Mark

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

Re: [Talk-it] Complesso residenziale

[demon.box]

Ciao, torno un attimo sulla questione.
Alla luce di quanto emerso negli ultimi giorni, cioè che l’indirizzo non si
mette sugli edifici (cosa che io sinceramente ignoravo, non ne faccio un
mistero) ho sistemato circa 600 “miei” oggetti, me me ne rimangono però
altri 300 che non ho al momento intenzione di sistemare in quanto legati ad
un POI.
Si tratta di amenity, leisure, shop, landuse=industrial, edifici interi sede
di azienda, ecc. e finchè non esiste una valida e condivisa regola
alternativa non mi pare per niente corretto smembrare il POI dal suo
indirizzo.
Potrò al massimo sistemarne un altro centinaio che sono gli agriturismi
visto che anzichè il POI sull’edificio intero credo possa andare benissimo
anche un nodo sull’edificio o nelle vicinanze ma i restanti sinceramente non
me la sento di toccarli.
Siete d’accordo?
Grazie

--enrico



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

[OSM-talk-fr] Vélo et data : nouvelles sources de données et nouveaux usages

[Jean-Christophe Becquet]

Bonjour,

Le Congrès de la FUB - vendredi 16 mars 2018 à Lyon
https://www.fub.fr/sites/fub/files/fub/AG_Congres/programme_je_web.pdf

Avec au programme une session qui pourrait intéresser des contributeurs
OSM :

Session 2 : Vélo et data : nouvelles sources de données et nouveaux
usages

Crowdsourcing, traces GPS, signalement : des données au service des
usagers et des planificateurs.


Sur ce même programme, un plan d'accès dont les aspects nouveau,
crowdsourcé et au service des usagers portent à discussion...

Bonne journée

JCB
-- 
Construisons ensemble vos solutions informatiques - Bonne année 2018 !
http://www.apitux.org/index.php?2018/01/01/255-voeux-2018

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [Talk-GB] OSM Conflator

[Ilya Zverev]

> I wrote up part 1 of my experience with OSM Conflator and the Community 
> Validation tool. This first part focuses on OSM Conflator explaining what it 
> does and the main components of it.
> 
> http://www.mappa-mercia.org/2018/01/osm-conflator.html

Thank you Rob, I enjoyed reading your post. I hope it drives more people to do 
their POI imports with the Conflator.

I have a single comment about "it assumes the third party data is correct and 
more up to date than any OSM data it is replacing". The third party data does 
indeed need to be correct, otherwise we should not import it into OSM. But in 
the profile "master_tags" property you choose a range of attributes that 
override these mapped by OSM members. For example, if you consider postcodes in 
OSM better than in the third party data, you don't add the "addr:postcode" to 
that list.

Also, nodes and areas are almost never moved, never for the initial import. 
Locations from OSM are considered to be the most precise. Of course, with the 
Community Validation tool mappers can adjust some locations to match these from 
a third party dataset.

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