Re: [Talk-lv] Fona karšu nobīdes

2020-05-28 Thread Maris Nartiss
Kam Tev WMS? Paņem no viņu datu sadaļas gatavus vektorus. Vienīgi
nezinu cik labi parastie OSM redaktori spēj nodrošināt vektordatu
nolasīšanu. Josmam laikam vispirms vajag tos ESRI Shapefile uz GeoJSON
vai ko tamlīdzīgu pārdzīt. Masveida imports gan būs problemātisks, jo
daudz kur tie ceļi jau ir sazīmēti — tad tur reāli jāvingro, lai
importējot nenonestu jau esošos (iespējams, ne tik precīzos) datus.

Vienīgi LVM GEO varētu pie datiem pielikt skaidras licences klāt.
Citādi šobrīd sanāk, ka saka jau ka drīkst izmantot, taču beigsies vēl
kā Pētera Valmieras datu importam — Valmiera teica, ka ņem un lieto
droši, taču papīra, ko parādīt citiem OSMistiem nav. Tā arī tas datu
imports aizgāja pa skuju taku.

Māris.

ceturtd., 2020. g. 28. maijs, plkst. 14:29 — lietotājs Marat
() rakstīja:
>
> Wow! Nezināju ka LVM piedalās OSM :)
> Off topic jautājums: vai ir iespējams dabūt LVM ceļu slāni ar nosaukumiem un 
> dabas takas WMSā?
>
> On Thu, 28 May 2020, 14:21 LVMGEO,  wrote:
>>
>> JS izmanto mūsu, LVM GEO ortofoto karšu servisus. Pērkam attēlus no LĢIA, 
>> publicējam visiem par brīvu izmantojamus, tai skaitā JS. Viss ir legāli, un 
>> to droši var lietot, vienīgi šobrīd mums ir tikai WMS serviss, diemžēl.
>>
>> -Original Message-
>> From: Rihards 
>> Sent: Wednesday, May 27, 2020 3:00 PM
>> To: talk-lvopenstreetmap.org 
>> Subject: Re: [Talk-lv] Fona karšu nobīdes
>>
>> On 27.05.20 13:47, Ivars wrote:
>> > Pēc maniem novērojumiem gan Esri, gan Jāņa sētas orto, gan LĢIA orto ir 
>> > viens un tas pats attēls, pāris atsevišķās Latvijas vietās paskatoties.
>> > Tā kā avots ir viens un tas pats, pieļauju, ka arī precizitātei vajadzētu 
>> > būt vienādai? Ja vien Esri nav kaut ko paši nepareizi pārbīdījuši.
>>
>> Var jau būt, ka Esri ir nomainījuši, tagad pamatā lietoju LKS un Maxar 
>> slāņus.
>> Paskatījos šībrīža rediģējamajā vietā - bilde tā pati, LKS vs Esri nedaudz 
>> virs metra atšķirība. Sīkums.
>> Kas ir JS orto nezinu, bet man ir lielas aizdomas, ka mēs to nedrīkstam 
>> lietot :)
>>
>> > Paldies par saiti uz LVM, visādi interesanti dati un servisi, ko līdz
>> > šim nezināju. iD editorā gan laikam tos nevar pielikt, jo tur custom maps 
>> > vajag TMS, nevis WMS...
>> > 99% esmu darbojies tikai iD, bet varbūt jāpamēģina vairāk ar JOSM
>>
>> Ja kādi jautājumi par JOSM (un par iD jau arī), droši šajā listē jāprasa.
>>
>> > - Reply to message -
>> > Subject: Re: [Talk-lv] Fona karšu nobīdes
>> > Date: Wed, 27 May 2020, 08:18
>> > From:  Rihards 
>> > To:  talk-lv@openstreetmap.org 
>> >> On 27.05.20 01:10, Ivars via Talk-lv wrote:
>> >>> Sveiki!
>> >>> Vai ir kaut kur informācija par to, kādas nobīdes ir pieejamajiem
>> >>> fona aero/satfoto slāņiem Latvijā?
>> >>> Vai Esri aerofoto (kas taču ir 1:1 tas pats JS aerofoto) var
>> >>> uzskatīt par visprecīzāko?
>> >>> Cik novēroju, Maxar uzņēmumi bieži ir vissvaigākie, bet tiem ir
>> >>> pamatīga nobīde, ko tad jāmēģina pielīdzināt.
>> >
>> >> ESRI šur tur ir labi foto, bet nobīde mēdz būt manāma.
>> >> Visprecīzākie tiešām līdz šim ir bijuši LVM publicētie LKS orto un
>> >> LIDAR slāņi - https://www.lvmgeo.lv/dati -> servisi.
>> >
>> >>> Un, ja, piemēram, esri ir precīzs vienā vietā, vai ir garantija, ka
>> >>> 3km tālāk tas joprojām būs tikpat precīzs?
>> >
>> >> Nē, pāris km tālāk var būt labi - bet var būt arī citādāka nobīde.
>> >
>> >>> Gps trasēm arī ne vienmēr var uzticēties un daudzviet viņu ir par
>> >>> maz (vai nav), lai pēc tām spriestu, cik metru pa labi, pa kreisi taka 
>> >>> ir.
>> >
>> >> GPX treisi ir manta, ja to ir daudz - tad pēc vidus var pieregulēt.
>> >> Ja tuvumā ir kāds lielāks krustojums, tad pa abām asīm var.
>> >
>> >>> Vai ir kaut kāds etalons, pēc kā var mēģināt vadīties, ja arī tas
>> >>> nav pieejams kā fons, bet tā, lai var paskatīties uz to un uz
>> >>> iekartēto osm un saprast, ir nobīde vai nav? Piemēram, Vzd kadastrā
>> >>> redzamajām māju un ceļu kontūrām taču vajadzētu atbilst "zemes 
>> >>> apstākļiem" par 99.9%?
>> >>>
>> >>> P.s. Nebiju līdz šim ar citiem LV kartētājiem kontaktējis - vai šis
>> >>> ir primārais saziņas veids vai ir kāds slepens forums, par ko nezinu, 
>> >>> arī?
>> >>> (Forum.osm.org users:lv zinu)
>> >
>> >> Ir primārais - bet varbūt Raitim pirms daudziem gadiem bija taisnība,
>> >> un vajag kaut ko normāliem cilvēkiem vieglāk pieejamu - kā forumu :)
>> >
>> >>> Ivars--
>> >> Rihards
>> --
>>  Rihards
>>
>> ___
>> Talk-lv mailing list
>> Talk-lv@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-lv
>> ___
>> Talk-lv mailing list
>> Talk-lv@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-lv
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv

___
Talk-lv mailing list
Talk-lv@openstreetmap.org

[OSM-talk] Search results quality (and some testing on Elasticsearch)

2020-05-28 Thread José Juan Montes
Hi all,

This is my first message to the list so I take the opportunity to say hello
to all and thanks to the community for the awesome software, data, and
organisation.

Now to the point. At the ES comunity, we've been discussing how difficult
is to obtain useful results from OSM. Too many times results are odd or
surprising: ordering puts better results down, sometimes it misses obvious
matches entirely... Specifically, we are referring about the search engine
of OSM front page, and other Nominatim bsaed services.

After some anaysis, issues seem related to:

- stop words usage (prepositions, articles...)
- result scoring and ordering (a perfect match placed below far and
unrelated results)
- word matching when there are tildes or non-unicode chars
- synonyms / ignoring for some categories and common nouns (street /
road...)
- lack of autocompletion (helps users finding a result when they don't
quite know the exact term)
- lack of cross-langugae search (eg. in regions with several official
languages, people mixes street names and road types between languages)
- support for typo errors

Part of the problem is that every language requires particular
considerations, which impacts most of the points above. So in my view, a
suitable solution would need to have good i18n support bottom up.

We think that other communities (language-wise) may be hitting the same
issues according to Github issues. I list some references at the bottom,
but they don't seem to get much attention.

Ultimately, the technology stack Nominatim is built upon is not state of
the art. I have done a quick test with Elasticsearch and a simple default
installation with naive data loading already produces decent results. I
later found that alternative search engines exist, for example "Pelias",
which are implemented on top of newer technologies, and their demo seems to
work fine...

Has any alternative to the current geocoder been tested? What would it take
for this to be improved? If alternatives exist, can the search engine at
the front page be changed? or provide options so users can choose their
preferred search engine? maybe even from specialized local/themed search
providers? Perhaps something like that would pave the way for alternative
search software and services, and foster innovation.

Cheers!

Refs:

- https://github.com/osm-search/Nominatim/issues/1811
- https://github.com/osm-search/Nominatim/issues/333
- https://github.com/osm-search/Nominatim/issues/1208
- https://wiki.openstreetmap.org/wiki/Search_engines
- source code of my tests:
https://github.com/jjmontesl/cubetl/tree/master/examples/osm


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


Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread Joseph Eisenberg
Could you provide a link to a particular location you are thinking of?

When I map farms in Papua, Indonesia, usually there is a central
residential compound with a few small houses and farm buildings, and
usually some shade and fruit trees right between the houses. I map that
residential area as landuse=residential. Sometimes there is a yard for
raising chickens and pigs or a large pig stye and dirt area nearby; that
can be mapped as landuse=farmyard. Then if there are vegetables gardens I
map those as landuse=farmland. Any fields planted with bananas or (fruit)
palms are landuse=orchard. Fallow fields are usually landuse=meadow if they
are covered in grass, though after a few years they turn back into
natural=scrub and eventually natural=wood - the locals use a very long
rotation period.

So, each area is mapped with what it is used for. This means that the
different landuse areas can be pretty small. E.g.:
https://www.openstreetmap.org/#map=17/-4.08508/138.73589

In the parts of Europe I've seen even smaller patches of different areas:
https://www.openstreetmap.org/#map=17/38.55129/-28.66001
That looks like a lot of work! It's totally okay to start by just mapping
large areas imprecisely, and then later we can get it down to very precise
mapping of thin strips of trees and scrub between fields:
https://www.openstreetmap.org/way/628402941 - if we want to

Joseph

On Thu, May 28, 2020 at 6:48 PM stevea  wrote:

> On May 28, 2020, at 5:12 PM, Joseph Eisenberg 
> wrote:
> > >  beekeeping, wild mushroom harvesting, herb-crafting for essential oils
> >
> > Those are all forest products, not so much farm products (though honey
> can come from any type of vegetation):
>
> So, do I use landuse=forest or the current landuse=farmland?  What I hear
> is that I must choose between landuse=forest and landuse=residential.  I
> describe "live on family farms in the forest which are partially though not
> necessarily rather forested areas which give rise to many kinds of
> agricultural production, right now, today, flexibly, as we speak."  They
> support families in residential areas simultaneously to whatever seemingly
> singular value I must compress into.  They flexible support vineyards,
> orchards and greenhouse_horticulture.  But, sir, who are you to ask where
> the edge of their residential aspect exists?  I say and property owners say
> (apparently, some renderer authors disagree, and that's certainly OK, I'm
> merely trying to understand it) expound 'the residential semantic' over the
> entire domain.  Anything else, to what we might loosely agree as Americans
> is a "5th amendment taking of property rights by the government."  If that
> sounds political, I guess that's where I say, "OK, diverges from Carto."
> Again, that's OK.  This is about me, Steve, understanding it.
>
> There is such a thing as "family owned 'farm' in the forest which does and
> might give rise to forest products and has some trees where people live in
> small family clusters in residential buildings."  If I need to fit all that
> into a single landuse tag I'd like you to tell me what it is and how it
> renders.  Families and agriculture and human life here on Earth is so much
> more complicated than that.  Thank you.
>
> > "Forest products include materials derived from a forest for commercial
> and personal use such as lumber, paper, and firewood as well as “special
> forest products” such as medicinal herbs, fungi, edible fruits and nuts,
> and other natural products."
> >
> > So, land covered with trees which is used to produce mushrooms,
> truffles, herbs, essential oils, honey, cork, bark, firewood, etc - that's
> forest or woodland, not landuse=farmland.
>
> OK, but people live here, too.  Which landuse value (with farmland out of
> the way), forest or residential?  I shouldn't have to choose.
>
> > > > Yes, the same area may be tree covered and residential at the same
> time.
>
> Of course, there are many of these.  How do we tag them?
>
> > > Yet, Mateusz, you don't say exactly how to tag these.
> >
> > You can just overlap them. Don't worry too much about how OpenStreetMap
> carto renders it, as long as they way you map it makes sense and matches
> reality. Perhaps we can fix the rendering if the current results are
> causing confusion, so that the trees only show when the green background
> shows.
>
> Examples of "how these are properly overlap" are appreciated.
>
> Changing how these layers render now would even-more-confuse.  Let's stick
> to how they do now.
>
> > > a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage,
> a small clearing
> >
> > Yeah, I would only map the cleared area as landuse=residential in that
> case, since the rest of the land is being used to grow trees, not for
> residential purposes. While the current owner may not plan to cut firewood
> or timber, the next owner might in another 20 or 30 years. Forestry is a
> long-term thing.
>
> Property ownership is a "as long as it exists, 

Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread stevea
It sounds like we are all on a "broad mind" of "channel what is known locally 
about land-use, deeply."  That is many different things around the world.  Let 
us keep a very open mind about how we characterize and categorize.  These are 
deep and difficult topics.

SteveA

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


Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread Kevin Kenny
On Thu, May 28, 2020 at 8:15 PM Joseph Eisenberg
 wrote:
> You can just overlap them. Don't worry too much about how OpenStreetMap carto 
> renders it, as long as they way you map it makes sense and matches reality. 
> Perhaps we can fix the rendering if the current results are causing 
> confusion, so that the trees only show when the green background shows.

Like Steve, I tend to overlap land use and land cover - which are two
distinct things.

I use 'landuse=forest' for 'the land is dedicated to the production of
forest products'.  Around here, such lands often, perhaps even
usually, have a secondary purpose of public recreation. This is true
even of privately-held ones; there are significant access easements,
for instance, to the forests owned in the Adirondacks by the paper
companies. I've certainly hiked on land owned by Finch Pruyn (when it
was still a going concern) and International Paper.  I use
'natural=wood' for 'this land is tree covered', and don't follow the
convention that some mappers do that it must be in some sense a
'natural' wood, and 'unmanaged', whatever that means. (In my part of
the world, the wilderness areas are among the most intensively managed
land in the country - to protect them!)

The strict taxonomists object to my use of 'landuse=forest' to denote
the land use - and want to require trees on every square metre. But
that's not the way a working forest works. In any given year, a given
piece of acreage may be grassland, scrub, marsh, open water, alder
thicket, or mature trees, depending on how long it's been since
harvest and what the beavers have been up to that year.  Despite the
awkward rendering, I do not cut the water and wetlands out of a forest
like https://www.openstreetmap.org/relation/6378266 - because the
whole thing is working forest, and the beaver activity changes, so
those ponds and marshes are actually less permanent than the use to
which the humans put the land.

'natural=wood' may overlay atop different land uses.  The grounds of
the mansion at https://www.openstreetmap.org/way/148531875 are largely
forested, and have a 'natural=wood' polygon overlaid, which also
extends over some of the adjoining protected_areas. (The mansion
grounds are not hard to trace in the field, since the NO TRESPASSING
posters can be spotted from the trails on all four sides.)  The
industrial areas like https://www.openstreetmap.org/way/479164244 and
https://www.openstreetmap.org/relation/7464551 are also partly wooded
- largely because in this part of the world, vacant land grows to
trees.  On other industrial sites, the gaps between buildings may be
grass, or bare dirt, or scrub land, or rubbish heaps, but here it
becomes either woodland or wetland.

I don't map orchards or forests as 'farmland'.  I don't mind layering
farm buiildings, residences, or greenhouses on top of 'farmland', and
don't make cutouts for them, but the renderers are happier with me if
I call orchards and forests separate things.

-- 
73 de ke9tv/2, Kevin

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


Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread Joseph Eisenberg
>  beekeeping, wild mushroom harvesting, herb-crafting for essential oils

Those are all forest products, not so much farm products (though honey can
come from any type of vegetation):

"Forest products include materials derived from a forest for commercial and
personal use such as lumber, paper, and firewood as well as “special forest
products” such as medicinal herbs, fungi, edible fruits and nuts, and other
natural products."

So, land covered with trees which is used to produce mushrooms, truffles,
herbs, essential oils, honey, cork, bark, firewood, etc - that's forest or
woodland, not landuse=farmland.

> > Yes, the same area may be tree covered and residential at the same time.

> Yet, Mateusz, you don't say exactly how to tag these.

You can just overlap them. Don't worry too much about how OpenStreetMap
carto renders it, as long as they way you map it makes sense and matches
reality. Perhaps we can fix the rendering if the current results are
causing confusion, so that the trees only show when the green background
shows.

> a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage, a
small clearing

Yeah, I would only map the cleared area as landuse=residential in that
case, since the rest of the land is being used to grow trees, not for
residential purposes. While the current owner may not plan to cut firewood
or timber, the next owner might in another 20 or 30 years. Forestry is a
long-term thing.

> 0% row crops, but allows (and actually develops) into orchards,
vineyards, greenhouse_horticulture.

It does not matter what is allowed by the local zoning laws. Don't map
zoning in OpenStreetMap, map what is actually there in reality. So, if they
plant a vineyard, map that as landuse=vineyard. But don't map
landuse=vineyard just because it's allowed to plant a vineyard someday.

– Joseph Eisenberg

On Thu, May 28, 2020 at 3:51 PM stevea  wrote:

> Mateusz Konieczny writes:
> > (quoting stevea)
>  "treed farmland" or "heavily wooded residential" prove slightly
> problematic to OSM tagging.
>
> Then, Mateusz Konieczny answers:
> > Map tree-covered area (landuse=forest) and map farmland
> (landuse=farmland) or residential (landuse=residential).  Yes, the same
> area may be tree covered and residential at the same time.
>
>
> If only it were this simple, it appears not to be.  "Tree covered area"
> can be either landuse=forest (OSM's wiki defines something like a
> half-dozed different conventions on how we actually tag this) OR it can be
> natural=wood.  Very roughly stated, what _I_ do (as I see other California
> and USA-based users doing this — I'm not trying to invent a new tagging
> method) is to map distinctly "timber production" areas as landuse=forest
> and distinctly "appears to be wooded — whether pristine and ancient
> never-cut forest I don't necessarily know — as natural=wood.  That is for
> starters and only attempts to start from a point of "visible trees" (as in
> imagery) while only leaning in the direction of landuse in the aspect of
> landuse=forest being "it is well-known that this is an area which is either
> actively forested, or has the right to have its trees felled" (timber
> permits, owned by a logging company, CAN be cut but maybe are still growing
> to maturity, MIGHT be cut but could also be deeded by owner later on to
> become conservation or land trust protected area...).  The possibilities
> are myriad, but OSM does a "fair to good" job of characterizing these, and
> with only two tags, forest and wood.  This isn't perfect nor is the
> consensus about how we do it, so that aspect alone complicates this
> question, while at least providing SOME stability of understanding the
> complex semantics.
>
> THEN there is the aspect of ALSO-has-a-residential-aspect (or perhaps
> PRIMARILY does).  Clearly, a 10 hectare / 25 acre parcel which is 98% trees
> and 2% house, garage, a small clearing and a driveway for access is
> something quite different than natural=wood (as far as its residential
> landuse goes).  However, it might not be all that different than a
> landuse=forest, ESPECIALLY if the residential land owner also has a timber
> permit to cut trees (possible, though not necessarily common, at least
> around here).
>
> Regarding farmland, this has also been discussed many times, especially
> about Santa Cruz County (see that topic's wiki, the fifth paragraph of the
> "Work to be done in the County" section).  Briefly, misunderstandings
> happen because around here, we have areas which are zoned farmland, (and
> are actually areas of — among other agricultural activities — beekeeping,
> wild mushroom harvesting, herb-crafting for essential oils, other unusual
> but certainly agricultural production) but also have significant
> tree-cover, which may or may not be permitted for felling timber.  That is
> a whole lot of complexity to shoehorn into a couple-few simple tagging
> "rules." (Or even "guidelines").  Two "admonishments" in that county-level
> wiki are 

[talk-ph] Data improvements in the Philippines

2020-05-28 Thread Andrew Wiseman via talk-ph
Hello talk-ph,

This is Andrew again from the Apple Maps team. We are planning to work on some 
data corrections and improvements to OSM in the Philippines around the road 
network — for example, sometimes there are missing roads or routing issues due 
to incorrect intersections or missing connections. We will make sure to follow 
the appropriate OSM and local guidelines.

In the future we also plan to do some improvements to coastal features and land 
use/land cover polygons, such as parks, university and hospital campuses, 
airports and similar features. Some examples may be things like coastlines and 
national parks that are missing a tag or are from old imports that may not be 
very accurate. I’ll reach out before we start that effort too. 

I wanted to see if you had any suggestions or feedback on the road network, 
such as if there are places we should take a look or other useful resources.

There is more information on our Github page: 
https://github.com/osmlab/appledata/issues/160

Thanks!

Andrew 

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 

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


Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread stevea
Mateusz Konieczny writes:
> (quoting stevea)
 "treed farmland" or "heavily wooded residential" prove slightly problematic to 
OSM tagging.

Then, Mateusz Konieczny answers:
> Map tree-covered area (landuse=forest) and map farmland (landuse=farmland) or 
> residential (landuse=residential).  Yes, the same area may be tree covered 
> and residential at the same time.


If only it were this simple, it appears not to be.  "Tree covered area" can be 
either landuse=forest (OSM's wiki defines something like a half-dozed different 
conventions on how we actually tag this) OR it can be natural=wood.  Very 
roughly stated, what _I_ do (as I see other California and USA-based users 
doing this — I'm not trying to invent a new tagging method) is to map 
distinctly "timber production" areas as landuse=forest and distinctly "appears 
to be wooded — whether pristine and ancient never-cut forest I don't 
necessarily know — as natural=wood.  That is for starters and only attempts to 
start from a point of "visible trees" (as in imagery) while only leaning in the 
direction of landuse in the aspect of landuse=forest being "it is well-known 
that this is an area which is either actively forested, or has the right to 
have its trees felled" (timber permits, owned by a logging company, CAN be cut 
but maybe are still growing to maturity, MIGHT be cut but could also be deeded 
by owner later on to become conservation or land trust protected area...).  The 
possibilities are myriad, but OSM does a "fair to good" job of characterizing 
these, and with only two tags, forest and wood.  This isn't perfect nor is the 
consensus about how we do it, so that aspect alone complicates this question, 
while at least providing SOME stability of understanding the complex semantics.

THEN there is the aspect of ALSO-has-a-residential-aspect (or perhaps PRIMARILY 
does).  Clearly, a 10 hectare / 25 acre parcel which is 98% trees and 2% house, 
garage, a small clearing and a driveway for access is something quite different 
than natural=wood (as far as its residential landuse goes).  However, it might 
not be all that different than a landuse=forest, ESPECIALLY if the residential 
land owner also has a timber permit to cut trees (possible, though not 
necessarily common, at least around here).

Regarding farmland, this has also been discussed many times, especially about 
Santa Cruz County (see that topic's wiki, the fifth paragraph of the "Work to 
be done in the County" section).  Briefly, misunderstandings happen because 
around here, we have areas which are zoned farmland, (and are actually areas of 
— among other agricultural activities — beekeeping, wild mushroom harvesting, 
herb-crafting for essential oils, other unusual but certainly agricultural 
production) but also have significant tree-cover, which may or may not be 
permitted for felling timber.  That is a whole lot of complexity to shoehorn 
into a couple-few simple tagging "rules." (Or even "guidelines").  Two 
"admonishments" in that county-level wiki are offered to prevent 
misunderstandings:  one is that "farmland isn't simply row crops" and the 
second is to read the definition of what our landuse=farmland wiki says (about 
"tillage," for example).  When both local zoning says "agricultural" and some 
activity like wildcrafting herbs to harvest essential oils both meet the 
definition of what I and others agree is "landuse=farmland," I tag these 
landuse=farmland.  These topics are complicated.  If we need more tags to 
better differentiate (I believe we do), let's coin them (with discussion and 
consensus, of course).  For example, locally, we distinguish between 
"Commercial Agricultural" (row crops), what most people would certainly agree 
is classically landuse=farmland, but we also have "Residential Agricultural," 
or what might be termed "a live-on family farm" which includes a residence / 
house and significant land, a large amount of which might be "treed," with 0% 
row crops, but allows (and actually develops) into orchards, vineyards, 
greenhouse_horticulture.  Indeed, I have tagged exactly those three latter tags 
on sub-polygons where I see them (as they are distinct tags in OSM), but in 
essence, it is 100% correct to tag the whole area landuse=farmland on the 
entire polygon (in my opinion), even though it is "also" residential.  OSM does 
not have "landuse=live-on-family-farm" as a tag, maybe we should better develop 
something like this and these.

> Yes, the same area may be tree covered and residential at the same time.

Yet, Mateusz, you don't say exactly how to tag these.  And (multi)polygons 
which describe them ARE (I know it, Doug knows it, many know it) and can be 
exceedingly complex structures to "get them right."

> Yes, "tree-covered area" meaning for landuse=forest mismatches strict meaning 
> of both landuse and forest

If only it were this simple, it appears not to be.  Again, I would go back to 
the (local? regional?) distinctions I make 

[Talk-us] Whole-US Garmin Map update - 2020-05-26

2020-05-28 Thread Dave Hansen
These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-05-26

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-05-26/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-05-26

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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


Re: [Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread Mateusz Konieczny via Talk-us



May 28, 2020, 23:54 by stevea...@softworkers.com:

> "treed farmland" or "heavily wooded residential" prove slightly problematic 
> to OSM tagging.
>
Map tree-covered area (landuse=forest) and map farmland (landuse=farmland) or
residential (landuse=residential).

Yes, the same area may be tree covered and residential at the same time.

Yes, "tree-covered area" meaning for landuse=forest mismatches strict meanning
of bot landuse and forest.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


[Talk-us] Heavily-wooded residential polygons

2020-05-28 Thread stevea
Fellow OSMer doug_sfba maps natural=wood edges around the southern and western 
areas of Silicon Valley (the South Bay Area in California), among other mapping 
and places.  I map similar things a bit further south, with initial emphasis on 
landuse, but as I sometimes combined natural tags in the same polygon, I now 
tend — as "more correct" — towards breaking these into two polygons, this is a 
fair bit of work.  Doug and I have collaborated a lot, and agree (among other 
things) that in OSM, there is a distinction between landUSE and landCOVER.  For 
example, "treed farmland" or "heavily wooded residential" prove slightly 
problematic to OSM tagging.  Due to complex tagging schemes on complex 
(multi)polygon construction (sometimes half-jokingly referred to as "higher 
math," though it is more like discrete math, topology and possibly its concept 
of "genus" or "holes in a complex surface") this can result in quite different 
results in the Carto renderer.

Recently, Doug and I discussed that Carto, areas of "heavily wooded 
residential" render with three possibilities, depending on some complex tagging 
strategies and the sizes of the underlying (multi)polygons:

• "fully gray," indicating pure residential, but leaving the human viewing 
Carto no indication the area is heavily wooded,
• "fully green-with-trees" (as natural=wood), which excludes the important 
aspect that while wooded, this is residential, or
• "gray with superimposed trees" (in both our opinions, a superior and pleasing 
method to display "heavily wooded residential").

For an example of the latter, see 
https://www.osm.org/query?lat=37.3769=-122.2506#map=15/37.3873/-122.2526 
and notice the residential areas surrounding Thornewood Open Space Preserve.

As I mentioned to Doug I exchanged a couple of emails with user:jeisenberg (a 
principal contributor to Carto) about what was going on with some examples of 
this, and Mr. Eisenberg explained to me (in short) that it is a complicated 
ordering (or re-ordering) of layers issue, both Doug and I continue to scratch 
our heads about what "best practice" might be here.  (For "heavily wooded 
residential" polygons, which are frequent in Northern California).  While Doug 
and I both tend towards the preference of the "superimposed look," it is not 
always simple to achieve, due to complexities in the renderer and data/tagging 
dependencies.  And, Doug and I are certainly aware of "don't code for the 
renderer."  However, given that Doug and I are fairly certain that others have 
noticed this, but aren't certain that others know what best to do (we don't, 
either), we ask the wider community "what do you think?" and "What are best 
practices here?"

Yes, the questions are a bit fuzzy and it is difficult to describe what is 
going on in the renderer (ordering or re-ordering of layers depending on size, 
I believe), but it does seem like we might be able to agree upon a best 
practice of "what to do."  In short, Doug and I both strive to "tag 
accurately," but just as "9" can be 5+4 or 6+3, there are many methods to 
combine and build polygons to describe an area and tag them accurately, though 
many combinations render differently.

This is being sent to both talk-us and the tagging list, where I think the 
latter may be a better place, but this was noticed by a couple of California 
mappers (for some time), so including talk-us might help widen the audience to 
include others who have noticed these anomalies.  Thank you in advance for good 
discussion.

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


Re: [OSM-talk-fr] Tagging/suppression d'un passage dangereux

2020-05-28 Thread André Maroneze
Merci pour vos suggestions, j'ai fait les changements. Je n'ai pas rajouté
le "kerb=raised" parce que la chaussée est au même niveau que le sol, donc
en pratique on n'a même pas de dénivelé. Mais j'ai appliqué les suggestions
de Marc M.

On Thu, May 28, 2020 at 5:04 PM Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Je rajouterais pour être plus constructif :
> La départementale à déjà de taggué sa vitesse max, son nombre de voie et
> son sens unique (maxspee=90 + lanes=2 + oneway=yes) ce qui permet déjà de
> qualifier un passage dangereux pour les piétons.
>
> En plus de crossing=unmarked il est possible d'ajouter la bordure,
> j'imagine qu'ici il n'y a pas de bordure abaissée donc
> kerb=raised sur le nœud d'intersection des ways. Ceci renforce l'idée d'un
> passage non officiel.
> https://wiki.openstreetmap.org/wiki/Key:kerb
>
> Le jeu. 28 mai 2020 à 12:02, Marc M.  a écrit :
>
>> Bonjour,
>>
>> Le 27.05.20 à 18:00, André Maroneze a écrit :
>> > Est-ce que "access=no" serait valide ici
>>
>> cela correspondrait à un panneau "interdit y compris piéton"
>> qui ne semble pas être présent.
>>
>> > semble que traverser une départementale à pied en dehors d'un passage
>> > piéton soit interdit ?
>>
>> seulement s'il y a un passage piéton à moins de 50m
>> https://fr.wikipedia.org/wiki/Passage_pi%C3%A9ton#R%C3%A9glementation
>>
>> > faudrait-il supprimer ce chemin
>>
>> non, il existe :)
>>
>> > https://www.openstreetmap.org/way/81972368
>> > Merci pour vos avis et suggestions,
>>
>> rajouter les 3 passages piétons non marqué
>> https://www.openstreetmap.org/node/5313575069
>> https://www.openstreetmap.org/node/5313575067
>> https://www.openstreetmap.org/node/955065661
>> highway=crossing crossing=unmarked
>> ainsi un routage peux tenir compte du danger.
>>
>> changer le tag note (info à destination d'un contributeur)
>> en description (info à destination de l'utilisateur final)
>>
>> supprimer le fixme
>>
>> rajouter surface (là aussi le routage peux en tenir compte)
>>
>> Cordialement,
>> Marc
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
> ___
> 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-GB] Farmfoods clean up

2020-05-28 Thread Cj Malone
Hello everyone,

I've gone through this and done what I can. I've gone through the OSM
listings and looked through Mapillary to add missing stores.

I didn't keep the stats as well as I intended to, but I now think there
are 327 Farmfoods stores, with 228 of them existing in OSM. They now
have brand data and website links. I decided not to add ref:store as I
couldn't think of a reason for it to exist in OSM.

I did use frozen_food, if anyone disagrees, just change it, I'm not
going to partake in edit wars over it.

There are still 99 missing from OSM, so it might be worth checking if
your local Farmfoods is listed, and if not adding it.

Cj



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


Re: [Talk-GB] Farmfoods clean up

2020-05-28 Thread Cj Malone
On Wed, 2020-05-27 at 12:01 +0100, Phil Endecott via Talk-GB wrote:
> Cj Malone wrote:
> > This also means shop=frozen_food, currently they are mainly
> > shop=supermarket
> 
> My local one was doing a roaring trade in 36-packs of loo roll
> a few weeks ago.  I believe they are also one of the cheapest
> places to get cans of coke.  So frozen_food sounds a bit too
> limited.

I don't think we should take the tag literally, the wiki says "used for
shops that mainly sell frozen food". I think that's a fair description
of Farmfoods.

Cj



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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread osm . sanspourriel

Très clairement il est écrit que les piétons sont prioritaires, c'est
donc un footway.

S'ils sont prioritaires c'est que d'autres usagers ceux à qui s'adresse
le panneau, ici les cyclistes, sont autorisés _en tant que tels_ et donc
sans mettre pied à terre : malgré les apparence ce n'est pas un trottoir !

On ne demande pas aux cyclistes de mettre pied à terre donc ils ont le
droit de rester, donc :

bicycle =yes

(ça correspond à ce qu'a tagué Simon).

ou plutôt permissive. "Where bicycles do not have a legal right-of-way,
but the land owner has indicated that bicycles are allowed".

Est-ce que sur ce qui semble être un trottoir il y a un panneau
avertissant les piétons de la circulation de cycles ? Rien vu depuis
Mapillary.

Par contre ce n'est pas sur cette liste mais avec la mairie ou la com
com qu'il faudrait voir afin d'avoir une continuité dans de bonnes
conditions.

En cas d'accident il serait possible de se retourner contre l'aménageur
car il semble que le piéton puisse de bonne foi se croire sur un
trottoir. Et le cycliste sur une voie qui lui est ouverte.

Mais à côté on voit aussi des piétons sur la voie cyclable
...

Jean-Yvon

Le 28/05/2020 à 17:27, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Bonjour,

On peut s'amuser à être légaliste lorsque l'infra est correctement
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.
Alors il faut je crois être raisonnable et essayer d'interpréter
l'intention de l'aménageur et surtout l'utilisation réelle.

Ici, surtout avec le panneau "attention aux piétons" et les logos de
sorties/entrées[1][2] il me semble que la continuité cyclable est de
rouler sur cet espace piéton/vélo.
Je garderais le bicycle=yes, voire en designated.
Je rajouterais que pour l'aspect légal, le trottoir n'étant pas
définit dans la loi on ne peut l'utiliser pour trancher la question ici :)

[1]
https://www.mapillary.com/app/?focus=photo=KJsoemkc4oYR4Xi5rqk2sQ=45.7528340908=4.86933412633=17=0.4937764232782991=0.5309130874519274=0
[2]
https://www.mapillary.com/app/?focus=photo=DZOXQywaxkgG0gIFFE9vBg=45.7527595999=4.86847119931=19.104624643089036=0.4927012280272741=0.5322403100702529=0

Le jeu. 28 mai 2020 à 15:26, Simon Réau mailto:simon.r...@geovelo.fr>> a écrit :

Bonjour,

Avec gileri  nous avons
un désaccord sur un highway=footway situé dans la continuité de
deux pistes cyclables. Notre discussion ce situe ici
https://www.openstreetmap.org/changeset/85822975#map=19/45.75301/4.86788

Le débat porte sur l'accès aux vélo sur cette partie entre les
deux pistes cyclables.

J'aimerais avoir l'avis de la communauté pour trancher la question.

La voie en question
https://www.openstreetmap.org/way/808726332
https://www.openstreetmap.org/way/808726333

Cordialement

Simon REAU
*
*

Simon REAU
GEOVELO
www.geovelo.fr 
simon.r...@geovelo.fr 
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours 

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



--
Florimond Berthoux

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


Re: [Talk-it] Richiesta su capacità/

2020-05-28 Thread Roberto Brazzelli
Ciao Alessandro,
per quanto riguarda i server io con server cloud 1) da 6 €/mese
mi trovo bene per piccoli/medi progetti.
Se avessi bisogni di coprire aree piu grandi sicuramente
dovresti fare un upgrade

Ciao
Roberto

1) https://www.hetzner.com/cloud


Il giorno lun 25 mag 2020 alle ore 08:22 Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> Grazie a tutti degli input, che mi saranno utili per dare qualche
> riferimento e indirizzo generale all'associazione, da approfondire poi
> quando avranno più chiari i loro obiettivi.
>
> Ale
>
>
> On 21/05/20 09:27, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 21. May 2020, at 05:50, Alessandro Sarretta
>   wrote:
>
> Ho visto che Switch2OSM (https://switch2osm.org/serving-tiles/) fornisce
> delle indicazioni e delle guide; sapete se ci sono altri portali, documenti
> o degli esempi di buone pratiche che descrivono nel dettaglio limiti e
> potenzialità?
>
>
>
> con un proprio server non ci sono limiti ;-)
> Non c’è una risposta semplice a questa domanda,  dipende quale siano le
> loro esigenze (mappe prerenderizzate di un singolo stile, oppure dinamiche
> (WMS ecc.), aggiornamento continuo o ogni tanto, vettoriali o raster,
> copertura Italia o globale, ecc.
>
> Generalmente switch2osm fornisce un’idea come fare.
>
> Ciao Martin
>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
> ___
> 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


[OSM-talk-fr] Assemblée générale 13/06

2020-05-28 Thread Donat ROBAUX
Bonsoir à tous-tes,

Juste un petit rappel des échéances.
Il vous reste jusqu'à demain soir donc le *vendredi 29 mai minuit* pour
- proposer des motions et sujets de discussion pour l'AG
- présenter votre candidature au CA.

Pour tout ca, envoyez un mail à associat...@listes.openstreetmap.fr

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


Re: [Talk-de] Massenweise Entfernung von oneway=no

2020-05-28 Thread Volker Schmidt
Alles ziemlich undeutlich. Kann mir mal jemand sagen wie sich "gesunder
Menschenverstand" in routing-Regeln umsetzen laesst? Das groesste Hindernis
ist dabei, dass dummerweise der "gesunde Menschenverstand" sehr
unterschiedlich ist.
Da kommen wir nicht weiter.

Allerdings haben wir schon einige Grundregeln fuer Aenderungen, ueber die
wir uns wohl einig sind:


   - Existierendes tagging darf nur in Einzelfaellen ohne Rueckspreache mit
   dem "Vortagger" geaenderte werden, und das nur dann, wenn das tagging
   falsch war, d.h entweder dem wiki oder der on-the-ground Situation
   widersprocht.
   - Das Entfernen anscheinend redundanter tags oder optionaler tags ist
   generell ohne Ruecksprache mit dem Autor ist unerwuenscht
   - Massenaenderungen sind immer wie Importe zu behandeln.


Wir brauchen wahrscheinlich eine neue Tabelle im wiki: "OSM tag for
routing/default values for highway tags"

Hier ein erster Versuch einer solchen "Tabelle auf die Schnelle":

highway=XXX;  mandatory value (highway type)
name=ABCDEFG; highly desirable; no default
ref=XXX; highly desirable for numbered roads
access tags - see wiki OSM_tags_for_routing/Access_restrictions

Note that for access tags there is an access hierarchy
.
It is desirable to use for any exclusion or permission the highest vehicle
in the hierarchy)
lanes=number ; desirable for all roads; no default (maybe optional for
single lane roads with explicit width or est_width values)
lit=yes|no|(conditional value); no default
maxspeed=number; mandatory value (for all road types, with the exception of
some motorways in Germany, and of minor ways like track; path, footway,
pedestrian) - there is also a wiki page OSM_tags_for_routing/Maxspeed
 which
contrasts with this !!!
layer=number; default value:0; mandatory in case of unconnected crossing
ways on one of the ways
surface=XXX; desirable for all ways; no default
smoothness=XXX; desirable for all ways; no default
oneway=yes|no|-1; desirable for all roads; default value "no"
bridge=XXX; mandatory for highways on bridges bridges; default value "no"
tunnel=yes|no|xxx; mandatory for highways in tunnels; default value "no"
embankment=yes|no; desirable for highways on embankmants; default value
"no"
cutting=yes|no; desirable for highways in cuttings; default value "no"
incline=up|down|xx%; optional or desiranìble?; default value 0
lit=yes|no; desirable on all highways; no default (maybe except track and
path with default value "no" ?)
width=xxx, desirable on highways with no lanes value and highly desirable
on sidewalks, foot/cycle ways, and foot/cycle lanes
sidewalk=lft|right|both|use_sidewalk; desirable on all road-type highway;
no default value
narrow=yes; optional; default value "no" (this is a strange tag, as it
refers to a *point* where the road is narrow)
Overhead trolly lines; optional; deafalut value "no"
tracktype=gradeX; optional on all types of minor highways; highly desirable
on tracks; no default
MTB_scale=X; not compatible with highways with implicit or explicit
bicycle=no; optional (useless) on paved highways; desirable on unpaved
paths; useful on unpaved tracks
SAC_scale=X; only compatible with minor highways; desirable on extra-urban
paths (definition???) and tracks
trail_visibility=xxx; optional; default value "excellent"
wheelchair=yes|no|limited; optional; no defined approach to default value
(could be default=yes on all highways that allow pedestrians and paved
surface with the exception of highway=path ?)
ski=yes|no optional; no default value
snow_mobile=yes|no optional; no default value
(there are some more of these winter-sports related tags)

Viel Spass beim Zerpfluecken

Volker











On Mon, 25 May 2020 at 22:25, Rainer via Talk-de 
wrote:

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


Re: [Talk-GB] Farmfoods clean up

2020-05-28 Thread Mike Baggaley via Talk-GB
I think the tag should indicate the primary market and should be consistent. 
From the Farmfoods home page, "Farmfoods are the Frozen Food Specialists. Our 
roots are embedded in the distribution and handling of frozen food."

That seems pretty definitive to me.

Supermarkets often sell a few books, records, home furnishings etc, but I would 
not think it sensible to tag them as bookstores or record shops.

Regards,
Mike

>My local one was doing a roaring trade in 36-packs of loo roll
>a few weeks ago.  I believe they are also one of the cheapest
>places to get cans of coke.  So frozen_food sounds a bit too
>limited.



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


Re: [OSM-talk-fr] Une résidence dans une zone résidentielle ?

2020-05-28 Thread osm . sanspourriel

Bonsoir,

Le 28/05/2020 à 20:37, Florian_G - forums+...@floriang.eu a écrit :

Bonsoir,

Le 28/05/2020 à 16:44, Jérôme Amagat a écrit :

Moi, j'utilise place=neighbourhood pour les lotissements et les
résidences mais sur des nodes.


Pas moi, enfin plus maintenant, car ça n'indique pas la limite. Du
coup, des applications (au hasard, Nominatim) peuvent l’utiliser à
mauvais escient.


Que nenni, si tu l'utilises /aussi/ avec une relation tu donnes une limite.

Si tu ne bornes pas on est d'accord ce n'est pas borné, même pas
semble-t-il par des polygones de Voronoï.

Si tu bornes, Nominatim ne semble pas dépasser de beaucoup !

Si tu ne bornes pas j'ai effectivement vu des hérésies par le passé. Là,
pour reprendre mon exemple précédent Nominatim est certes dans l'erreur
: Swimming Pool Piscine Fit Océa Guidel, Rue Général De Gaulle, Les
Jardins de Vitalis, Kerprat, Guidel, Lorient, Morbihan, Bretagne, France
métropolitaine, 56520, France 

Mais c'est le segment précédent de la rue qui correspond aux Jardins de
Vitalis. C'est donc un cas tangent ;-).

Jean-Yvon

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


Re: [OSM-talk-fr] Une résidence dans une zone résidentielle ?

2020-05-28 Thread Florian_G
Bonsoir,

Le 28/05/2020 à 16:44, Jérôme Amagat a écrit :
> Moi, j'utilise place=neighbourhood pour les lotissements et les
> résidences mais sur des nodes.

Pas moi, enfin plus maintenant, car ça n'indique pas la limite. Du coup,
des applications (au hasard, Nominatim) peuvent l’utiliser à mauvais
escient.

> Par contre le problème, c'est que le rendu ne rend pas les place=*
> surfaciques seulement les nodes […]

Pas tous : les place=square surfaciques sont bien rendus par le rendu
par défaut. Mais au pire c'est pas grave, tant que l'information est là.
Il y aura bien un rendu qui les rendra. :-)

> Donc en fait, la solution que je préférés en cas de résidence
> représentée par une surface c'est en plus de place=neighbourhood
> d'ajouter landuse=residential :)
> Ce n'est pas faux, c'est bien une zone résidentielle, elle fait partie
> d'une zone résidentielle plus grande mais une partie de zone
> résidentielle est bien une zone résidentielle :)

^_^

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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Bryce Cogswell via talk

> On May 28, 2020, at 9:38 AM, Andy Townsend wrote:
> 
> It sounds like he's learnt something really useful about the computer 
> representation of written characters!

This page generates all manner of font variations for a name:
http://qaz.wtf/u/convert.cgi?text=OpenStreetMap

퐎퐩퐞퐧퐒퐭퐫퐞퐞퐭퐌퐚퐩
핺햕햊햓핾햙햗햊햊햙핸햆햕
푶풑풆풏푺풕풓풆풆풕푴풂풑
퓞퓹퓮퓷퓢퓽퓻퓮퓮퓽퓜퓪퓹
핆핡핖핟핊핥핣핖핖핥필핒핡
etc.

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


Re: [OSM-talk-fr] osm11 osm12 osm13 indisponible en ipv4 (ipv6 ok) : impact bano, cadastre, cyclosm, download, osmose (maj)

2020-05-28 Thread Marc M.
l'hébergeur avait changé les adresses ipv4.
les config ont été modifiée. le dns a été modifié vers 17h.
avec le cache dns, la modif peux durer jusqu'à 20h.
n'hésitez pas à signaler tous disfonctionnement après cette heure.

Le 28.05.20 à 10:54, Marc M. a écrit :
> Bonjour,
> 
> depuis hier environ 20h30, ces 3 serveurs sont injoignable en ipv4.
> j'ai envoyé un message à l'hébergeur et j'ai modifiés quelques bricoles
> pour restaurer ce qui pouvait l'être partiellement dans l'état actuel.
> 
> Cordialement,
> Marc
> 


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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Yves P.

>> Ici, surtout avec le panneau "attention aux piétons" et les logos de 
>> sorties/entrées
> 
> Si c'était le cas, pourquoi mettre ce panneau plutôt que le B54 et B55, ou 
> C113/C114 ?
Je vois les B54 et B55 signalant une aire piétonne 

 quand je circule en voiture sur une voie qui devient ou croise une aire.

Les panneaux C113/C114 indiquants une piste ou bande cyclable conseillée et 
réservée aux cycles 

 ne sont pas adaptés ici : c'est fait à la base pour les piétons :)

__
Yves

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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Yves P.
> Alors il faut je crois être raisonnable et essayer d'interpréter l'intention 
> de l'aménageur et surtout l'utilisation réelle.
Oui

> Ici, surtout avec le panneau "attention aux piétons" et les logos de 
> sorties/entrées[1][2] il me semble que la continuité cyclable est de rouler 
> sur cet espace piéton/vélo.
C'est clair.

> Je rajouterais que pour l'aspect légal, le trottoir n'étant pas définit dans 
> la loi on ne peut l'utiliser pour trancher la question ici :)
Effectivement, pas de définition de trottoir dans l'Article R110-2 
<https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI39277970=LEGITEXT06074228=20200528>
 du code de la route.

Pour moi, cette zone est une aire piétonne. Voir ici 
<https://www.mapillary.com/map/im/UJ4n1F9Gz09SjMGKiYqg-w>.

"un trottoir ne peut pas être assimilé à une aire piétonne.
Par contre, un grand parvis (par exemple plus de 100 m²) ou une grande place 
peuvent être une aire piétonne."
Source <https://www.au5v.fr/IMG/pdf/plaquette_certu_aire_pietonne_nov2008.pdf>

J'ai mesuré pour le fun ce que Eric assimile à un trottoir. Il mesure 324 m². 
(La "place" entière mesure 888  m²)

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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Andy Townsend

On 28/05/2020 17:29, mbranco2 wrote:
햒햆햘햙햗햔  has all to do with mastro, because it's the surname of a 
student in an Italian high school where I'm teaching  OSM  :-)


It sounds like he's learnt something really useful about the computer 
representation of written characters!


Best Regards,

Andy


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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread mbranco2
햒햆햘햙햗햔  has all to do with mastro, because it's the surname of a
student in an Italian high school where I'm teaching  OSM  :-)
His classroom is participating in a mapathon for UN (
https://tasks.teachosm.org/project/998), commenting changeset withs
#AAvogadroONU.
When I asked him how he registered in OSM, he told me that he likes gothic
font, and in every social he registered in that way (writing his surname in
gothic with a wordprocessor, and copying/pasting it in the registering form.

Surely I agree everyone in the world must be able to register using
characters of his language, but I supposed that the sequence to  change the
font character is something different from characters in other alphabets
(sorry, I'm not an expert of character encoding, maybe this is not true).
Or maybe we could use nicknames  also bolded, underlined, ...

Il giorno gio 28 mag 2020 alle ore 15:30 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> On 28. May 2020, at 15:08, mbranco2  wrote:
>
> I was surprised finding an OSM username written in gothic characters: I'm
> not sure if this mailing list could show such font, the
> nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to
> copy and paste his name written with such font, searching with
> osm.org/user/mastro give no results.
>
> Isn't this an anomaly?
>
>
>
> it’s normal, we allow unicode characters for usernames, and there is no
> tolerant “search“ behind osm.org/user/username
> AGAIK it requires the exact string (maybe whitespace trimmed) that the
> mapper has used for registering.
> If the user had written in a different script which you do not have
> available on your keyboard you would have had equally to use copy+paste (or
> click on a link to the user).
>
>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if
> it has.
>
> Cheers Martin
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Éric Gillet

Le 28/05/2020 à 17:27, Florimond Berthoux a écrit :
On peut s'amuser à être légaliste lorsque l'infra est correctement 
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.


Je souhaite juste que les infras cyclistes et leurs défauts soient 
correctement représentées. Cela permet d'informer les cyclistes sur les 
zones pas pratiques voir dangereuses et pouvoir remonter les problèmes 
de continuité aux municipalités afin que ça bouge. Si l'on masque tous 
ces problèmes à coup de bicycle=yes afin que le routeur soit content ça 
fait pas avancer les choses.


Alors il faut je crois être raisonnable et essayer d'interpréter 
l'intention de l'aménageur et surtout l'utilisation réelle.


Entièrement d'accord. D'ailleurs ici l'infrastructure est dangereuse 
pour la cohabitation vélo/piéton comme par exemple ici [1]. Bollards 
serrés,  passage entre l'arbre et le rebord étroit, passage piéton pas 
assez large. Ça fait au moins 3 ans que c'est comme ça.


Ici, surtout avec le panneau "attention aux piétons" et les logos de 
sorties/entrées


Si c'était le cas, pourquoi mettre ce panneau plutôt que le B54 et B55, 
ou C113/C114 ?


il me semble que la continuité cyclable est de rouler sur cet espace 
piéton/vélo.


S'il y a une voie cyclable aux deux extrémités d'une autoroute, cela 
rend-t-il cette dernière accessible aux vélos ?



Je garderais le bicycle=yes, voire en designated.
Rien ne désigne le vélo comme autorisé sur cette place piétonne, ce 
serait encore moins adapté qu'un bicycle=yes.
Je rajouterais que pour l'aspect légal, le trottoir n'étant pas 
définit dans la loi


Ça veut dire qu'on peut esquiver l'amende de classe 4 si on roule sur 
les trottoirs ? Super pratique ! Est-ce que t'aurais une source si 
jamais j'en ai besoin ? Merci :)



[1] https://www.mapillary.com/map/im/VEthNOBZrieZWyqy-pNmnQ


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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Steve Friedl
> If there is any real problem here, it could be with people using names that 
> look like the names of other community members (but technically are 
> different) for abusive scopes

Can I be Ṡtereo ? :-)

-Original Message-
From: Martin Koppenhoefer  
Sent: Thursday, May 28, 2020 8:38 AM
To: Oleksiy Muzalyev 
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)



sent from a phone

> On 28. May 2020, at 17:20, Oleksiy Muzalyev  
> wrote:
> 
> Practically all people in Russia studied a foreign language within the 
> compulsory education system. ... I am sure that typing several Latin letters 
> would not be a challenge.
> 
> Besides in such disciplines as mathematics or chemistry the Latin letters are 
> being used widely for variables in formulas, etc.
> Customarily, a keyboard with the Russian layout has got also the Latin 
> letters on the keys (buttons) [1].
> 
> I do not know exactly about Japan and China, but I guess that it is about the 
> same there too.


I think the question is not so much whether someone not usually writing in 
latin characters will be able to do it, but more whether a name written in 
latin is suitable for them to identify with. IMHO there is great benefit in 
allowing unicode names, and very little problem with people using “strange 
looking” characters to mean something in different than what the characters are 
originally intended for.

If there is any real problem here, it could be with people using names that 
look like the names of other community members (but technically are different) 
for abusive scopes. This shouldn’t be tolerated of course, and would be 
individually reacted to by the admins, if it is detected.

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: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Martin Koppenhoefer


sent from a phone

> On 28. May 2020, at 17:20, Oleksiy Muzalyev  
> wrote:
> 
> Practically all people in Russia studied a foreign language within the 
> compulsory education system. ... I am sure that typing several Latin letters 
> would not be a challenge.
> 
> Besides in such disciplines as mathematics or chemistry the Latin letters are 
> being used widely for variables in formulas, etc.
> Customarily, a keyboard with the Russian layout has got also the Latin 
> letters on the keys (buttons) [1].
> 
> I do not know exactly about Japan and China, but I guess that it is about the 
> same there too.


I think the question is not so much whether someone not usually writing in 
latin characters will be able to do it, but more whether a name written in 
latin is suitable for them to identify with. IMHO there is great benefit in 
allowing unicode names, and very little problem with people using “strange 
looking” characters to mean something in different than what the characters are 
originally intended for.

If there is any real problem here, it could be with people using names that 
look like the names of other community members (but technically are different) 
for abusive scopes. This shouldn’t be tolerated of course, and would be 
individually reacted to by the admins, if it is detected.

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


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Rpnpif via Talk-fr

Le 28/05/2020 à 17:16, Jean-Claude Repetto a écrit :

Je parlais bien de place=locality:
https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dlocality
qui est traduit par lieu-dit dans OSM. 


Euh, je lis « lieu-dit sans population » :


/Locality/ désigne un lieu-dit (au sens littéral du terme) sans 
population. Les lieux-dits (dans le langage courant) ou hameaux 
peuplés doivent être tagués avec place 
=hamlet 
.



Ce qui est exact.

--

Rpnpif

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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Florimond Berthoux
Bonjour,

On peut s'amuser à être légaliste lorsque l'infra est correctement
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.
Alors il faut je crois être raisonnable et essayer d'interpréter
l'intention de l'aménageur et surtout l'utilisation réelle.

Ici, surtout avec le panneau "attention aux piétons" et les logos de
sorties/entrées[1][2] il me semble que la continuité cyclable est de rouler
sur cet espace piéton/vélo.
Je garderais le bicycle=yes, voire en designated.
Je rajouterais que pour l'aspect légal, le trottoir n'étant pas définit
dans la loi on ne peut l'utiliser pour trancher la question ici :)

[1]
https://www.mapillary.com/app/?focus=photo=KJsoemkc4oYR4Xi5rqk2sQ=45.7528340908=4.86933412633=17=0.4937764232782991=0.5309130874519274=0
[2]
https://www.mapillary.com/app/?focus=photo=DZOXQywaxkgG0gIFFE9vBg=45.7527595999=4.86847119931=19.104624643089036=0.4927012280272741=0.5322403100702529=0

Le jeu. 28 mai 2020 à 15:26, Simon Réau  a écrit :

> Bonjour,
>
> Avec gileri  nous avons un
> désaccord sur un highway=footway situé dans la continuité de deux pistes
> cyclables. Notre discussion ce situe ici
> https://www.openstreetmap.org/changeset/85822975#map=19/45.75301/4.86788
>
> Le débat porte sur l'accès aux vélo sur cette partie entre les deux pistes
> cyclables.
>
> J'aimerais avoir l'avis de la communauté pour trancher la question.
>
> La voie en question
> https://www.openstreetmap.org/way/808726332
> https://www.openstreetmap.org/way/808726333
>
> Cordialement
>
> Simon REAU
>
> Simon REAU
> GEOVELO
> www.geovelo.fr
> simon.r...@geovelo.fr
> Tél : 06 77 15 59 86
> 1 Impasse du Palais, 37000 Tours 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Oleksiy Muzalyev
Practically all people in Russia studied a foreign language within the 
compulsory education system. Usually it is English, French, or German.
How well they may know the language is debatable, however I am sure that 
typing several Latin letters would not be a challenge.


Besides in such disciplines as mathematics or chemistry the Latin 
letters are being used widely for variables in formulas, etc.
Customarily, a keyboard with the Russian layout has got also the Latin 
letters on the keys (buttons) [1].


I do not know exactly about Japan and China, but I guess that it is 
about the same there too.


[1] 
https://www.pngfind.com/pngs/m/326-3264221_russian-keyboard-layout-norwegian-keyboard-layout-windows-hd.png


On 28-May-20 15:28, Maarten Deen wrote:
I'm sure this is a feature that's very helpful for everyone not 
writing in latin script (Russia, China, Japan, etc).




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


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Jean-Claude Repetto

Le 28/05/2020 à 17:04, Rpnpif via Talk-fr a écrit :


Un lieu-dit, mot générique, peut avoir des habitants ou pas car place 
signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant, 
c'est place=locality.


Je parlais bien de place=locality:
https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dlocality
qui est traduit par lieu-dit dans OSM.

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


Re: [OSM-talk-fr] Mappons le temporaire qui dur

2020-05-28 Thread Florimond Berthoux
Il y a simplement end_date pour préciser la date prévu de fin d'une feature.

Le jeu. 28 mai 2020 à 14:18, Marc M.  a écrit :

> Bonjour,
>
> Le 27.05.20 à 16:22, Florimond Berthoux a écrit :
> > explicitement marqué par un panneau un début et de fin, etc.
>
> pour le début start_date
> pour la fin : il serrait utile d'avoir un tag pour encoder
> une date à partir de laquelle il faudrait retourner voir
> si le temporaire a été prolongé ou si cela a changé.
> une sorte de opening_date inversé -> ending_date ?
>
> > contrôle qualité pour lister les aménagements à vérifier régulièrement.
>
> survey:date pourrait être utile pour cela lorsque la vérif
> sur place ne nécessite aucun changement dans osm parce que
> rien n'a changé.
> ou alors un changement blanc mais c'est tordu et
> source de confusion pour les autres contributeurs.
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] Tagging/suppression d'un passage dangereux

2020-05-28 Thread Florimond Berthoux
Je rajouterais pour être plus constructif :
La départementale à déjà de taggué sa vitesse max, son nombre de voie et
son sens unique (maxspee=90 + lanes=2 + oneway=yes) ce qui permet déjà de
qualifier un passage dangereux pour les piétons.

En plus de crossing=unmarked il est possible d'ajouter la bordure,
j'imagine qu'ici il n'y a pas de bordure abaissée donc
kerb=raised sur le nœud d'intersection des ways. Ceci renforce l'idée d'un
passage non officiel.
https://wiki.openstreetmap.org/wiki/Key:kerb

Le jeu. 28 mai 2020 à 12:02, Marc M.  a écrit :

> Bonjour,
>
> Le 27.05.20 à 18:00, André Maroneze a écrit :
> > Est-ce que "access=no" serait valide ici
>
> cela correspondrait à un panneau "interdit y compris piéton"
> qui ne semble pas être présent.
>
> > semble que traverser une départementale à pied en dehors d'un passage
> > piéton soit interdit ?
>
> seulement s'il y a un passage piéton à moins de 50m
> https://fr.wikipedia.org/wiki/Passage_pi%C3%A9ton#R%C3%A9glementation
>
> > faudrait-il supprimer ce chemin
>
> non, il existe :)
>
> > https://www.openstreetmap.org/way/81972368
> > Merci pour vos avis et suggestions,
>
> rajouter les 3 passages piétons non marqué
> https://www.openstreetmap.org/node/5313575069
> https://www.openstreetmap.org/node/5313575067
> https://www.openstreetmap.org/node/955065661
> highway=crossing crossing=unmarked
> ainsi un routage peux tenir compte du danger.
>
> changer le tag note (info à destination d'un contributeur)
> en description (info à destination de l'utilisateur final)
>
> supprimer le fixme
>
> rajouter surface (là aussi le routage peux en tenir compte)
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Rpnpif via Talk-fr

Le 28/05/2020 à 15:29, Jean-Claude Repetto a écrit :

Bonjour,

Je réponds partiellement:

Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit :


Je me permets d'écrire sur cette liste, merci de me dire si ce n'est 
pas le bon endroit. J'ai envoyé un message sur le forum, mais j'ai 
l'impression que ma question aura peut-être plus de chances de 
réponses sur cette liste !


Oui, cette liste est beaucoup plus active que le forum.

"Saint-M'Hervon" a été engloutie par la commune de 
"Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit, 
est-ce ok ?


Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus 
approprié.


Bonjour,

Un lieu-dit, mot générique, peut avoir des habitants ou pas car place 
signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant, 
c'est place=locality.


Et bien se souvenir que il n'y a malheureusement aucun rendu pour le 
moment des communes nouvelles issues de la fusion sur la carte 
officielle https://www.openstreetmap.org/ sauf, comme dans ce cas, si la 
commune ne change pas de nom. Dans ce cas et autrement, on ne voit que 
les communes anciennes sur la carte, marquées par un point place=village 
ou bien place=* (autre). Alors que pour toutes les communes anciennes 
fusionnées ou pas, un point place=* est placé traditionnellement en plus 
de la frontière sous forme de relation même si la commune ancienne 
comprend plusieurs place=village (agglomérations de plus de 200 
habitants). La raison est que les relations comportant le nom de la 
commune nouvelle ne sont pas malheureusement non plus rendues (sauf le 
long de la frontière de la commune en tout petit).


La carte https://www.openstreetmap.org/ a choisi de ne pas représenter 
les surfaces place=* pour une raison qui m'est inconnue contrairement à 
l'application OsmAnd.


Comme la communauté française a choisi de ne pas ajouter de point 
place=* pour les communes nouvelles (alors que pour les habitants de 
plus en plus celles-ci sont entrées dans la vie quotidienne entre autres 
pour des raisons postales et de transports) et bien ces communes sont 
invisibles sur ce rendu comme sur celui de openstreetmap.fr.


Dommage.

--
Rpnpif


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


Re: [OSM-talk-fr] Une résidence dans une zone résidentielle ?

2020-05-28 Thread Jérôme Amagat
Moi, j'utilise place=neighbourhood pour les lotissements et les résidences
mais sur des nodes.

> En terme de taille et pour Nantes tu as raison : neighbourhood c'est trop
> grand.
>
Le problème est peut être le choix fait à Nantes d'utiliser
place=neighbourhood
Il y a place=quarter entre place=suburb et place=neighbourhood
de plus pour Nantes il y a le découpage administratif niveau 10 et 11, qui
peut être différent des véritables quartiers qui portent le même nom.
D’ailleurs pour certain "quartiers" administratifs, le nom est composé de 2
noms accolés représentant 2 quartiers différents. Donc les quartiers au
sens le plus courant (même sens qu'osm) n'ont pas la superficie des
quartiers administratifs.

Rien ne dit non plus que place=neighbourhood a une taille minimum, c'est
juste plus petit que place=quarter. city_block pour moi est peu adapté à la
France et est pour moi un bloc compacte d'habitation séparer du reste par
des rues. plot c'est censé être une parcelle, je ne crois pas qu'il faille
l'utiliser. Dans osm, pas de parcelle cadastrale, et place=* est censé
toujours être utilisé avec name=* ce qui ne semble pas être obligatoire ici
d'après le wiki et place=* n'est rendu que pour les nodes alors qu'ici il
faudrait une surface.

Par contre le problème, c'est que le rendu ne rend pas les place=*
surfaciques seulement les nodes et ajouter un label avec les même tag sur
un node, c'est donc avoir 2 objets pour la même chose, ce qu'il ne faut pas
faire dans osm...

Donc en fait, la solution que je préférés en cas de résidence représentée
par une surface c'est en plus de place=neighbourhood d'ajouter
landuse=residential :)
Ce n'est pas faux, c'est bien une zone résidentielle, elle fait partie
d'une zone résidentielle plus grande mais une partie de zone résidentielle
est bien une zone résidentielle :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Roland Olbricht
See 
https://www.openstreetmap.org/user/%F0%9D%96%92%F0%9D%96%86%F0%9D%96%98%F0%9D%96%99%F0%9D%96%97%F0%9D%96%94
URL-Percent-Encoding works fine, so does the involved XML. It is
solely a problem of UX software.

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


Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui cartelli segnaletici del CAI

2020-05-28 Thread Luca Delucchi
On Thu, 28 May 2020 at 14:36, Andrea Mazzoleni  wrote:
>
>
> Ma scusate, è un così grosso problema se io aggiungo il numero del sentiero 
> così come è scritto sul cartello ? Non è che sto inventando cose strane...
>

secondo me ti stai complicando la vita, puoi fare quello che vuoi
basta che vai contro le linee guida. Se vuoi aggiunge qualcosa puoi
usare description:it/note:it e mettere quello che vuoi

>
> Ciao,
> Andrea
>

-- 
ciao
Luca

www.lucadelu.org

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


Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui cartelli segnaletici del CAI

2020-05-28 Thread Nogaro
Direi che se il bivio non è visibile dal punto in cui c'è il cartello, metti 
solo il tratto iniziale in comune in entrambe le relazioni. Se la way del 
tratto iniziale si prolunga oltre il bivio, la spezzi al bivio. In fondo è una 
ambiguità che il cartello non ti risolve, per risolverla è necessario un altro 
cartello al bivio, o che tu conosca le destinazioni in altro modo. La relazione 
descrive solo le informazioni fornite dal cartello.

Alle volte invece capita che il bivio sia pochissimi metri dopo il cartello, 
tanto che guardando le direzione in cui sono orientate le frecce del cartello 
già si capisce che direzione prendere dopo il primo breve tratto comune. Capita 
ad esempio quando si usa un cartello solo per descrivere due intersezioni molto 
ravvicinate. In questo caso metterei con ruolo intersection proprio il bivio 
che si trova dopo il primo tratto comune, e con ruolo to le way già dopo il 
bivio.

Per il riferimento numerico, potresti aggiungere alla relazione il valore 
destination:ref, come descritto qui:

https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:ref

Ciao, 
Alberto 

From: Andrea Mazzoleni  
Sent: 28 May 2020 14:35
To: openstreetmap list - italiano 
Subject: Re: [Talk-it] [Talk-it-cai] Mappare il 

Sicuramente la relazione "destination_sign=" è meglio, infatti pensavo di 
usarla invece di mettere il guidepost nella relazione del sentiero. Ma non 
copre ancora tutti i casi possibili. Proprio nel cartello menzionato, due 
sentieri hanno un tratto iniziale in comune. E questo ricrea l'ambiguità (anche 
se si può in qualche modo risolvere associando il tratto di sentiero dopo il 
bivio anche se distante dal cartello).

Ed inoltre si sta associando la direzione, ma non il sentiero inteso come 
riferimento numerico.




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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Éric Gillet

Le 28/05/2020 à 15:54, Yves P. a écrit :
Le trottoir semble être une /"aire piétonne"/ dans le jargon du 
législateur.


Une aire piétonne est signalée par les panneaux B54 et B55, qui ne sont 
pas présents ici. Plus d'infos ici :


https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_aire_pi%C3%A9tonne_en_France

Le panneau attention cylistes n'a pas vraiment de valeur légale, c'est 
juste pour appeler à la vigilance car en effet beaucoup de cyclistes 
circulent malgré l'interdiction.


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


Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Yves P.

> Le débat porte sur l'accès aux vélo sur cette partie entre les deux pistes 
> cyclables.

Le panneau B40 indique la fin d'une piste cyclable (exclusivement réservée aux 
cyclistes à 2 ou 3 roues).
Panneau de signalisation d'une piste ou bande cyclable obligatoire en France 
<https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d'une_piste_ou_bande_cyclable_obligatoire_en_France>

Le trottoir semble être une "aire piétonne" dans le jargon du législateur.

"Les conducteurs de cycles peuvent circuler sur les aires piétonnes dans les 
deux sens, sauf dispositions différentes prises par l'autorité investie du 
pouvoir de police, à la condition de conserver l'allure du pas et de ne pas 
occasionner de gêne aux piétons."
Source 
<https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=EA2F5398CD9EE334EFC05838D7A3473B.tplgfr34s_2?idArticle=LEGIARTI30851697=LEGITEXT06074228=20200528>

C'est d'ailleurs ce qu'indique le panonceau "Cyclistes attention ! 
<https://www.mapillary.com/map/im/aUVsaQFUPJnRwU3xbnZcnA>".

Pour moi c'est clair, un vélo peut circuler ici (sans même descendre de sa 
monture).

Après, que la zone soit mal conçue, mal balisée, est un autre problème.

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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Hartmut Holzgraefe
On 2020-05-28 15:27, Mateusz Konieczny via talk wrote:
> See case of anyone from Russia or Łukasz from Poland.

or people from Germany who were not as lucky as me who had
the 'ä' in the family name converted to ASCII-friendly 'ae'
some generations ago already (due to a transmission error
at the town hall, nobody would even have known about ASCII
back in those days ...)

-- 
hartmut


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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Mateusz Konieczny via talk



May 28, 2020, 15:38 by martin.zd...@freemap.sk:

> On Thu, May 28, 2020 at 3:34 PM Martin Koppenhoefer <> 
> dieterdre...@gmail.com> > wrote:
>
>>
>>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if it has.
>>
>
> Google has different opinion ;-)
>
"햒햆햘햙햗햔 has nothing to do with mastro" seems to be something unique to Unicode

https://en.wikipedia.org/wiki/Fraktur#Fraktur_in_Unicode

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


[OSM-talk]  | Re: OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Rory McCann

ha! Awesome!

My OSM username is like that. It's so out there that I am unable to log 
into the OSM Forum, & help.osm.org. When I try to put it on the wiki 
directly, it deletes the whole page. It's great fun.  ⁽¹⁾


It's a nice way to find unicode bugs in OSM software.

(And remember: people can change their usernames)

⁽¹⁾ Much less software broke than I thought.

On 28/05/2020 15:02, mbranco2 wrote:

Hallo,
I was surprised finding an OSM username written in gothic characters: 
I'm not sure if this mailing list could show such font, the 
nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've to 
copy and paste his name written with such font, searching with 
osm.org/user/mastro  give no results.


Isn't this an anomaly?

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



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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Martin Ždila
On Thu, May 28, 2020 at 3:34 PM Martin Koppenhoefer 
wrote:

>
>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if
> it has.
>

Google has different opinion ;-)

-- 
Martin Ždila
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Martin Koppenhoefer


sent from a phone

> On 28. May 2020, at 15:08, mbranco2  wrote:
> 
> I was surprised finding an OSM username written in gothic characters: I'm not 
> sure if this mailing list could show such font, the nickname is 햒햆햘햙햗햔 
> ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to copy 
> and paste his name written with such font, searching with osm.org/user/mastro 
> give no results.
> 
> Isn't this an anomaly?


it’s normal, we allow unicode characters for usernames, and there is no 
tolerant “search“ behind osm.org/user/username 
AGAIK it requires the exact string (maybe whitespace trimmed) that the mapper 
has used for registering.
If the user had written in a different script which you do not have available 
on your keyboard you would have had equally to use copy+paste (or click on a 
link to the user).

 햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if it has.

Cheers Martin 



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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Tom Hughes via talk

On 28/05/2020 14:02, mbranco2 wrote:

I was surprised finding an OSM username written in gothic characters: 
I'm not sure if this mailing list could show such font, the 
nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've to 
copy and paste his name written with such font, searching with 
osm.org/user/mastro  give no results.


Isn't this an anomaly?



So we shouldn't allow people who don't use the latin
alphabet to register using names in their native language?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Jean-Claude Repetto

Bonjour,

Je réponds partiellement:

Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit :


Je me permets d'écrire sur cette liste, merci de me dire si ce n'est pas 
le bon endroit. J'ai envoyé un message sur le forum, mais j'ai 
l'impression que ma question aura peut-être plus de chances de réponses 
sur cette liste !


Oui, cette liste est beaucoup plus active que le forum.

"Saint-M'Hervon" a été engloutie par la commune de 
"Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit, 
est-ce ok ?


Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus 
approprié.




J'ai un petit doute sur la méthodo car le rendu OSM m'affiche toujours 
les communes de "Saint-M'Hervon" et "La-Chapelle-du-Lou" à un certain 
niveau de zoom, au niveau du seuil 12 pour, dès le seuil 13, m'afficher 
les bons noms modifiés.


La mise à jour de la carte affichée peut prendre quelques heures, et 
parfois plusieurs jours !


Jean-Claude

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


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Julien Lepiller
Le 28 mai 2020 08:45:22 GMT-04:00, "Yann-Gaël LARGILLET"  
a écrit :
>Salut à tous, 
>
>Je me permets d'écrire sur cette liste, merci de me dire si ce n'est
>pas
>le bon endroit. J'ai envoyé un message sur le forum, mais j'ai
>l'impression que ma question aura peut-être plus de chances de réponses
>sur cette liste ! 
>
>Contexte : MAJ des noms de communes dans OSM suite à fusion sur le
>territoire. Il s'agit de "Saint-M'Hervon" et
>"La-Chapelle-du-Lou-du-Lac"
>à l'ouest de Rennes en Ille-et-Vilaine -->
>https://www.openstreetmap.org/#map=12/48.2254/-2.0623 
>
>"Saint-M'Hervon" a été engloutie par la commune de
>"Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit,
>est-ce ok ? 
>
>"La-Chapelle-du-Lou-du-Lac" est la fusion de 2 communes :
>"La-Chapelle-du-Lou" et "Le Lou du Lac". La mairie de cette nouvelle
>commune se trouvant dans l'ancienne de "La-Chapelle-du-Lou", j'ai donc
>renommer le point "La-Chapelle-du-Lou" en "La-Chapelle-du-Lou-du-Lac"
>et
>j'ai transformé le point "Le Lou du Lac" en lieu-dit, est-ce ok ? 
>
>J'ai un petit doute sur la méthodo car le rendu OSM m'affiche toujours
>les communes de "Saint-M'Hervon" et "La-Chapelle-du-Lou" à un certain
>niveau de zoom, au niveau du seuil 12 pour, dès le seuil 13, m'afficher
>les bons noms modifiés. 
>
>J'ai bien compris qu'il ne faut pas cartographier OSM dans l'optique
>"rendu" mais n'y aurait-il pas un autre paramètre à modifier ? Au
>niveau
>des limites administratives ? Ou ailleurs ? J'ai voulu modifier les
>"admin_level" mais je ne voudrais pas me tromper... 
>
>Merci à vous, 
>
>Yann-Gaël

C'est simplement une question de temps de rendu et de cache. Ça va finir par 
converger :)

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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Mateusz Konieczny via talk
See case of anyone from Russia or Łukasz from Poland.

Or people from China/Japan.

While banning some characters may be reasonable it is complex,
and unlikely to be very important.


May 28, 2020, 15:02 by mbran...@gmail.com:

> Hallo,
> I was surprised finding an OSM username written in gothic characters: I'm not 
> sure if this mailing list could show such font, the nickname is 햒햆햘햙햗햔 
> ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to copy 
> and paste his name written with such font, searching with > 
> osm.org/user/mastro >  give no results.
>
> Isn't this an anomaly?
>

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


Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread Maarten Deen

On 2020-05-28 15:02, mbranco2 wrote:

Hallo,
I was surprised finding an OSM username written in gothic characters:
I'm not sure if this mailing list could show such font, the nickname
is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've
to copy and paste his name written with such font, searching with
osm.org/user/mastro [1] give no results.

Isn't this an anomaly?


I'm sure this is a feature that's very helpful for everyone not writing 
in latin script (Russia, China, Japan, etc). I'm sure there are many 
users that have their name written in Cyrillic or Hanzi or Kanji but I 
can't give examples because I can't enter those letters.

I won't call it an anomaly but an inconvenience.

Regards,
Maarten

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


[OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread Simon Réau
Bonjour,

Avec gileri  nous avons un
désaccord sur un highway=footway situé dans la continuité de deux pistes
cyclables. Notre discussion ce situe ici
https://www.openstreetmap.org/changeset/85822975#map=19/45.75301/4.86788

Le débat porte sur l'accès aux vélo sur cette partie entre les deux pistes
cyclables.

J'aimerais avoir l'avis de la communauté pour trancher la question.

La voie en question
https://www.openstreetmap.org/way/808726332
https://www.openstreetmap.org/way/808726333

Cordialement

Simon REAU

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Marc M.
Bonjour,

Le 28.05.20 à 14:45, Yann-Gaël LARGILLET a écrit :
> J'ai donc transformé le point en lieu-dit, est-ce ok ?

je ne connais pas le coin, je répond donc de manière générale.

dans osm, les points/nœuds représente souvent des villages ou hameaux.
lorsqu'une commune A ayant un village du même nom, fusionne avec la
commune B ayant un village du même nom, le nom de ces 2 villages
continuent d'exister, il ne faut donc pas modifier les place=city/
town/village/hamlet

les communes sont toutes représentées en France par une relation
et c'est donc à ce niveau là que les modifications de fusion interviennent.
il est courant de garder les anciennes relation en ajoutant un end_date
ou en les transformant en commune déléguée selon le cas,
puis de créer une nouvelle relation pour la commune fusionnée
ou étendre la relation existante si elle garde le même nom.

> J'ai un petit doute sur la méthodo car le rendu OSM m'affiche toujours
> les communes de "Saint-M'Hervon" et "La-Chapelle-du-Lou" à un certain
> niveau de zoom, au niveau du seuil 12 pour, dès le seuil 13, m'afficher
> les bons noms modifiés.

les différents niveau de zoom ne se mettent pas à jour en même temps.
les plus lourds ne sont fait qu'une fois par semaine.
Et sauf erreur, le rendu standard ignore les communes.

Cordiaelement,
Marc

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


[OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

2020-05-28 Thread mbranco2
Hallo,
I was surprised finding an OSM username written in gothic characters: I'm
not sure if this mailing list could show such font, the
nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've to
copy and paste his name written with such font, searching with
osm.org/user/mastro give no results.

Isn't this an anomaly?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-se] Talk-se Digest, Vol 145, Issue 18

2020-05-28 Thread Tomas Marklund
Eller, en alternativ och mer allmängiltig lösning: utan att veta nåt om
målgruppen så väljer man det format som är gångbart på alla plattformar.
Ett liggande format som visas på en telefon är inget problem, eftersom man
lätt kan vrida telefonen i handen och därmed maximera fylladsgraden på
skärmen. Inte lika lätt att vrida en datorskärm eller tv för att uppnå
samma resultat, där måste man istället leva med svarta kanter på hälften
(eller mer) av skärmytan.

Men eftersom videoformatet är ett sidospår som inte tillför nåt till
sakfrågan så ska jag vara tyst framgent :)

Den tors 28 maj 2020 kl 13:11 skrev Per Geijer :

> Hej Tomas,
>
> Det är lätt att sitta framför en dator och tro att stående format är helt
> kokobello, men majoriteten av konsumtionen av film på nätet sker på
> mobiltelefoner. För att kunna göra det bästa valet för just det här
> projektet måste man veta mer om målgruppen, men utan att veta någonting om
> den så är stående format sannolikt bäst.
>
> Hälsningar från en gamling med barn, som jobbar professionellt med filmer
> till bl a Youtube.
> //Per
>
> > 28 maj 2020 kl. 13:00 skrev talk-se-requ...@openstreetmap.org:
> >
> > Send Talk-se mailing list submissions to
> >   talk-se@openstreetmap.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >   https://lists.openstreetmap.org/listinfo/talk-se
> > or, via email, send a message with subject or body 'help' to
> >   talk-se-requ...@openstreetmap.org
> >
> > You can reach the person managing the list at
> >   talk-se-ow...@openstreetmap.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Talk-se digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Förfrågan från Wikimedia Sverige (Karl Wettin)
> >   2. Re:  Förfrågan från Wikimedia Sverige (Tomas Marklund)
> >
> >
> > --
> >
> > Message: 1
> > Date: Wed, 27 May 2020 15:35:46 +0200
> > From: Karl Wettin 
> > To: "talk-se@openstreetmap.org e-postlista"
> >   
> > Subject: [Talk-se] Förfrågan från Wikimedia Sverige
> > Message-ID:
> >j6opgb14+tzqfeuv-9-8qxzdp...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Wikimedia Sverige undrar om vi kan tänka oss att spela in en liten film
> > (max 55 sekunder lång) i stående format på en telefon där man berättar
> lite
> > om varför OSM är bra. Filmen måste vara CC-BY (eller bättre) då den
> kommer
> > distribueras av dem.
> >
> > Är det någon här som kan tänka sig att spela in och vara huvudpersonen i
> > denna film? Som anställd av Wikimedia Sverige upplever jag det som att
> jag
> > sitter på lite för många stolar och har lite för många hattar på mig för
> > att vara den som är med på denna film och uttrycker sina åsikter.
> >
> > Jag tycker det är rimligt att den som spelar in filmen har fullt mandat
> att
> > föra fram sina subjektiva åsikter. Samtidigt är det juste om vi,
> > gemenskapen, tillsammans först kan prata lite om vad det är som gör OSM
> bra
> > för att ge lite vägledande tankar. Dock är det väldigt svårt att summera
> > det på 55 sekunder.
> >
> > Eftersom de flesta som kommer se filmen inte vet hur OSM skiljer sig från
> > tex en tryckt karta på ett papper så tror jag det är bra att fokusera på
> > att det handlar om geografisk rådata och att kartan bara är ett av många
> > tänkbara resultat av att arbeta med denna data. Den kan användas till att
> > skapa en reseplaneringsmjukvara. En biodlare kan ställa en GIS-fråga för
> > att leta upp lämpliga innergårdar i stadsmiljö nära kolonilotter för att
> > ställa ut kupor. Din bil skulle kunna rekommendera dig att parkera runt
> > hörnet så solen smälter frosten på fönsterrutan åt dig på morgonen. Att
> HOT
> > på riktigt räddat liv när gemenskapen kommit samman och skapat kartor åt
> > räddningsarbetare i katastrofområden.
> >
> > Är det någon som känner sig manad att ta denna pucken? Jag borde
> egentligen
> > inte skriva det, men vill ingen så kan jag göra det.
> >
> > Värt att nämna i detta mejl är att Wikimedia Sverige är de som för många
> år
> > sedan ursprungligen sponsrat OpenStreetMap Sverige med server, och nu i
> > veckorna med nya hårddiskar till denna då de gamla brunnit upp. Så det är
> > en liten gentjänst från oss till dem att göra det här.
> >
> >
> > Kalle
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <
> http://lists.openstreetmap.org/pipermail/talk-se/attachments/20200527/acc6e141/attachment-0001.htm
> >
> >
> > --
> >
> > Message: 2
> > Date: Wed, 27 May 2020 16:01:37 +0200
> > From: Tomas Marklund 
> > To: OpenStreetMap Sverige mailinglista 
> > Subject: Re: [Talk-se]  Förfrågan från Wikimedia Sverige
> > Message-ID:
> >s27s-gp57qx-6-py8myvs0ilidyh...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Stående format? Suck.. Skicka tillbaka den här till dem :)
> >
> > 

[OSM-talk-fr] Rendu OSM et fusion de communes

2020-05-28 Thread Yann-Gaël LARGILLET
Salut à tous, 

Je me permets d'écrire sur cette liste, merci de me dire si ce n'est pas
le bon endroit. J'ai envoyé un message sur le forum, mais j'ai
l'impression que ma question aura peut-être plus de chances de réponses
sur cette liste ! 

Contexte : MAJ des noms de communes dans OSM suite à fusion sur le
territoire. Il s'agit de "Saint-M'Hervon" et "La-Chapelle-du-Lou-du-Lac"
à l'ouest de Rennes en Ille-et-Vilaine -->
https://www.openstreetmap.org/#map=12/48.2254/-2.0623 

"Saint-M'Hervon" a été engloutie par la commune de
"Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit,
est-ce ok ? 

"La-Chapelle-du-Lou-du-Lac" est la fusion de 2 communes :
"La-Chapelle-du-Lou" et "Le Lou du Lac". La mairie de cette nouvelle
commune se trouvant dans l'ancienne de "La-Chapelle-du-Lou", j'ai donc
renommer le point "La-Chapelle-du-Lou" en "La-Chapelle-du-Lou-du-Lac" et
j'ai transformé le point "Le Lou du Lac" en lieu-dit, est-ce ok ? 

J'ai un petit doute sur la méthodo car le rendu OSM m'affiche toujours
les communes de "Saint-M'Hervon" et "La-Chapelle-du-Lou" à un certain
niveau de zoom, au niveau du seuil 12 pour, dès le seuil 13, m'afficher
les bons noms modifiés. 

J'ai bien compris qu'il ne faut pas cartographier OSM dans l'optique
"rendu" mais n'y aurait-il pas un autre paramètre à modifier ? Au niveau
des limites administratives ? Ou ailleurs ? J'ai voulu modifier les
"admin_level" mais je ne voudrais pas me tromper... 

Merci à vous, 

Yann-Gaël

-- 
"Lentius, Profundius, Suavius" (A.Langer)___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui cartelli segnaletici del CAI

2020-05-28 Thread Andrea Mazzoleni
On Thu, May 28, 2020 at 1:48 PM Nogaro  wrote:

> Una possibilità per indicare a quale sentiero si riferisce una
> destinazione è quella di usare una relazione destination_sign per ciascuna
> destinazione
>
Sicuramente la relazione "destination_sign=" è meglio, infatti pensavo di
usarla invece di mettere il guidepost nella relazione del sentiero. Ma non
copre ancora tutti i casi possibili. Proprio nel cartello menzionato, due
sentieri hanno un tratto iniziale in comune. E questo ricrea l'ambiguità
(anche se si può in qualche modo risolvere associando il tratto di sentiero
dopo il bivio anche se distante dal cartello).
Ed inoltre si sta associando la direzione, ma non il sentiero inteso come
riferimento numerico.

Ma scusate, è un così grosso problema se io aggiungo il numero del sentiero
così come è scritto sul cartello ? Non è che sto inventando cose strane...

Probabilmente faro entrambe le cose, "destination_sign=" più il testo
completo sul cartello.

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


Re: [OSM-talk-fr] Mappons le temporaire qui dur

2020-05-28 Thread Marc M.
Bonjour,

Le 27.05.20 à 16:22, Florimond Berthoux a écrit :
> explicitement marqué par un panneau un début et de fin, etc.

pour le début start_date
pour la fin : il serrait utile d'avoir un tag pour encoder
une date à partir de laquelle il faudrait retourner voir
si le temporaire a été prolongé ou si cela a changé.
une sorte de opening_date inversé -> ending_date ?

> contrôle qualité pour lister les aménagements à vérifier régulièrement.

survey:date pourrait être utile pour cela lorsque la vérif
sur place ne nécessite aucun changement dans osm parce que
rien n'a changé.
ou alors un changement blanc mais c'est tordu et
source de confusion pour les autres contributeurs.

Cordialement,
Marc

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


Re: [Talk-it] [Import] civici Bergamo

2020-05-28 Thread Andrea Musuruane
Prima di continuare a fare QA, possiamo concordare sul sistemare
l'esistente, secondo quanto scritto sulla wiki e di conseguenza informare
la ML di import?

Per quanto riguarda gli esponenti numerici, sono 87 nel dataset del comune
ma in OSM ce ne sono solo 66. Quindi ne mancano 21.

[out:json][timeout:25];
area[name="Bergamo"][admin_level=8]->.searchArea;
node["addr:housenumber"~"[0-9]+\/[0-9]+"](area.searchArea);
out body;
>;
out skel qt;

Ciao,

Andrea


On Thu, May 28, 2020 at 1:37 PM Cascafico Giovanni 
wrote:

> Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap dipo che
> mapnik ha aggiornato ci vorrebbe
>
> Il gio 28 mag 2020, 12:08 Andrea Musuruane  ha
> scritto:
>
>> Li hai corretti tu?
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni 
>> wrote:
>>
>>> Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.
>>>
>>> Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha
>>> scritto:
>>>
 Ciao a tutti,
 ho provato a documentare questo import sulla wiki:

 https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import

 Se concordate, per procedere e mantenere i dati importati in OSM,
 bisogna fare tanta QA. I casi che ho trovato sono elencati nella wiki. Non
 escludo che lavorandoci più attivamente sopra, se ne scoprano altri.

 Ciao,

 Andrea


 On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
 wrote:

> Ciao,
>
> On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni <
> cascaf...@gmail.com> wrote:
>
>> Ho standardizzato i civici, rimuovendo la barra e portando a maiusolo
>> l'esponente.
>>
>
> Perché in maiuscolo?
>
> Prima di continuare (chiunque), possiamo almeno scrivere una pagina di
> import che descrivere le cose fatte/da fare?
>
> Lato mio posso: a) fare uno script di conversione con ogr2osm b)
> suggerire di usare come modello la pagina di import che avevo fatto per
> Biella
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
>
> Grazie,
>
> Andrea
>
> ___
 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
>>>
>> ___
>> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui cartelli segnaletici del CAI

2020-05-28 Thread Nogaro
Una possibilità per indicare a quale sentiero si riferisce una destinazione è 
quella di usare una relazione destination_sign per ciascuna destinazione (o 
anche solo per ciascuna direzione, elencando più valori nel tag destination).

 

Vedi per esempio questo caso di guidepost con due destinazioni:

 

https://www.openstreetmap.org/relation/5639854#map=19/45.86692/9.49243 

 =N

https://www.openstreetmap.org/relation/3061362#map=18/45.86689/9.49260 

 =N

 

E’ un po' più laborioso, ma può essere usato anche quando le destinazioni non 
vengono raggiunte seguendo un itinerario per cui si può creare una realzione 
route.

 

Ciao,

Alberto

 

From: Gabriele Sani via Talk-it  
Sent: 28 May 2020 09:16
To: openstreetmap list - italiano 
Cc: Gabriele Sani ; Lista_Cai_OSM 

Subject: Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui 
cartelli segnaletici del CAI

 

Capisco cosa intendi ma mi sembra ridondante e piu' complicato da mantenere 
della relazione d'appartenenza. E' vero che un utente al momento, guardando 
come sono mappati i segnaposti "doppi", non puo' inferire a che sentiero 
corrisponde una specifica localita' indicata in destination, ma puo' capirlo 
incrociando i dati che ha.

 

Nel caso che hai portato dell'immagine 

https://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/20200517-costa_del_palio-42.jpg/800px-20200517-costa_del_palio-42.jpg

guardando le relazioni a cui apparterrebbe il segnavia (571 e 577) capisco 
subito che l'indicazione per Brumano non puo' essere relativa al 571 (dato che 
da li il percorso non passa) e quindi sra' relativa al 577.

 

Gabriele Sani

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


Re: [Talk-it] [Import] civici Bergamo

2020-05-28 Thread Cascafico Giovanni
Ne ho fatti una ventina, sembrano tutti. Una rivista alla umap dipo che
mapnik ha aggiornato ci vorrebbe

Il gio 28 mag 2020, 12:08 Andrea Musuruane  ha scritto:

> Li hai corretti tu?
>
> Ciao,
>
> Andrea
>
>
> On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni 
> wrote:
>
>> Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.
>>
>> Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha
>> scritto:
>>
>>> Ciao a tutti,
>>> ho provato a documentare questo import sulla wiki:
>>>
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
>>>
>>> Se concordate, per procedere e mantenere i dati importati in OSM,
>>> bisogna fare tanta QA. I casi che ho trovato sono elencati nella wiki. Non
>>> escludo che lavorandoci più attivamente sopra, se ne scoprano altri.
>>>
>>> Ciao,
>>>
>>> Andrea
>>>
>>>
>>> On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
>>> wrote:
>>>
 Ciao,

 On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni 
 wrote:

> Ho standardizzato i civici, rimuovendo la barra e portando a maiusolo
> l'esponente.
>

 Perché in maiuscolo?

 Prima di continuare (chiunque), possiamo almeno scrivere una pagina di
 import che descrivere le cose fatte/da fare?

 Lato mio posso: a) fare uno script di conversione con ogr2osm b)
 suggerire di usare come modello la pagina di import che avevo fatto per
 Biella
 https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses

 Grazie,

 Andrea

 ___
>>> 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
>>
> ___
> 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-lv] Fona karšu nobīdes

2020-05-28 Thread Marat
Wow! Nezināju ka LVM piedalās OSM :)
Off topic jautājums: vai ir iespējams dabūt LVM ceļu slāni ar nosaukumiem
un dabas takas WMSā?

On Thu, 28 May 2020, 14:21 LVMGEO,  wrote:

> JS izmanto mūsu, LVM GEO ortofoto karšu servisus. Pērkam attēlus no LĢIA,
> publicējam visiem par brīvu izmantojamus, tai skaitā JS. Viss ir legāli, un
> to droši var lietot, vienīgi šobrīd mums ir tikai WMS serviss, diemžēl.
>
> -Original Message-
> From: Rihards 
> Sent: Wednesday, May 27, 2020 3:00 PM
> To: talk-lvopenstreetmap.org 
> Subject: Re: [Talk-lv] Fona karšu nobīdes
>
> On 27.05.20 13:47, Ivars wrote:
> > Pēc maniem novērojumiem gan Esri, gan Jāņa sētas orto, gan LĢIA orto ir
> viens un tas pats attēls, pāris atsevišķās Latvijas vietās paskatoties.
> > Tā kā avots ir viens un tas pats, pieļauju, ka arī precizitātei
> vajadzētu būt vienādai? Ja vien Esri nav kaut ko paši nepareizi pārbīdījuši.
>
> Var jau būt, ka Esri ir nomainījuši, tagad pamatā lietoju LKS un Maxar
> slāņus.
> Paskatījos šībrīža rediģējamajā vietā - bilde tā pati, LKS vs Esri nedaudz
> virs metra atšķirība. Sīkums.
> Kas ir JS orto nezinu, bet man ir lielas aizdomas, ka mēs to nedrīkstam
> lietot :)
>
> > Paldies par saiti uz LVM, visādi interesanti dati un servisi, ko līdz
> > šim nezināju. iD editorā gan laikam tos nevar pielikt, jo tur custom
> maps vajag TMS, nevis WMS...
> > 99% esmu darbojies tikai iD, bet varbūt jāpamēģina vairāk ar JOSM
>
> Ja kādi jautājumi par JOSM (un par iD jau arī), droši šajā listē jāprasa.
>
> > - Reply to message -
> > Subject: Re: [Talk-lv] Fona karšu nobīdes
> > Date: Wed, 27 May 2020, 08:18
> > From:  Rihards 
> > To:  talk-lv@openstreetmap.org 
> >> On 27.05.20 01:10, Ivars via Talk-lv wrote:
> >>> Sveiki!
> >>> Vai ir kaut kur informācija par to, kādas nobīdes ir pieejamajiem
> >>> fona aero/satfoto slāņiem Latvijā?
> >>> Vai Esri aerofoto (kas taču ir 1:1 tas pats JS aerofoto) var
> >>> uzskatīt par visprecīzāko?
> >>> Cik novēroju, Maxar uzņēmumi bieži ir vissvaigākie, bet tiem ir
> >>> pamatīga nobīde, ko tad jāmēģina pielīdzināt.
> >
> >> ESRI šur tur ir labi foto, bet nobīde mēdz būt manāma.
> >> Visprecīzākie tiešām līdz šim ir bijuši LVM publicētie LKS orto un
> >> LIDAR slāņi - https://www.lvmgeo.lv/dati -> servisi.
> >
> >>> Un, ja, piemēram, esri ir precīzs vienā vietā, vai ir garantija, ka
> >>> 3km tālāk tas joprojām būs tikpat precīzs?
> >
> >> Nē, pāris km tālāk var būt labi - bet var būt arī citādāka nobīde.
> >
> >>> Gps trasēm arī ne vienmēr var uzticēties un daudzviet viņu ir par
> >>> maz (vai nav), lai pēc tām spriestu, cik metru pa labi, pa kreisi taka
> ir.
> >
> >> GPX treisi ir manta, ja to ir daudz - tad pēc vidus var pieregulēt.
> >> Ja tuvumā ir kāds lielāks krustojums, tad pa abām asīm var.
> >
> >>> Vai ir kaut kāds etalons, pēc kā var mēģināt vadīties, ja arī tas
> >>> nav pieejams kā fons, bet tā, lai var paskatīties uz to un uz
> >>> iekartēto osm un saprast, ir nobīde vai nav? Piemēram, Vzd kadastrā
> >>> redzamajām māju un ceļu kontūrām taču vajadzētu atbilst "zemes
> apstākļiem" par 99.9%?
> >>>
> >>> P.s. Nebiju līdz šim ar citiem LV kartētājiem kontaktējis - vai šis
> >>> ir primārais saziņas veids vai ir kāds slepens forums, par ko nezinu,
> arī?
> >>> (Forum.osm.org users:lv zinu)
> >
> >> Ir primārais - bet varbūt Raitim pirms daudziem gadiem bija taisnība,
> >> un vajag kaut ko normāliem cilvēkiem vieglāk pieejamu - kā forumu :)
> >
> >>> Ivars--
> >> Rihards
> --
>  Rihards
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv


Re: [Talk-lv] Fona karšu nobīdes

2020-05-28 Thread LVMGEO
JS izmanto mūsu, LVM GEO ortofoto karšu servisus. Pērkam attēlus no LĢIA, 
publicējam visiem par brīvu izmantojamus, tai skaitā JS. Viss ir legāli, un to 
droši var lietot, vienīgi šobrīd mums ir tikai WMS serviss, diemžēl.

-Original Message-
From: Rihards  
Sent: Wednesday, May 27, 2020 3:00 PM
To: talk-lvopenstreetmap.org 
Subject: Re: [Talk-lv] Fona karšu nobīdes

On 27.05.20 13:47, Ivars wrote:
> Pēc maniem novērojumiem gan Esri, gan Jāņa sētas orto, gan LĢIA orto ir viens 
> un tas pats attēls, pāris atsevišķās Latvijas vietās paskatoties.
> Tā kā avots ir viens un tas pats, pieļauju, ka arī precizitātei vajadzētu būt 
> vienādai? Ja vien Esri nav kaut ko paši nepareizi pārbīdījuši.

Var jau būt, ka Esri ir nomainījuši, tagad pamatā lietoju LKS un Maxar slāņus.
Paskatījos šībrīža rediģējamajā vietā - bilde tā pati, LKS vs Esri nedaudz virs 
metra atšķirība. Sīkums.
Kas ir JS orto nezinu, bet man ir lielas aizdomas, ka mēs to nedrīkstam lietot 
:)

> Paldies par saiti uz LVM, visādi interesanti dati un servisi, ko līdz 
> šim nezināju. iD editorā gan laikam tos nevar pielikt, jo tur custom maps 
> vajag TMS, nevis WMS...
> 99% esmu darbojies tikai iD, bet varbūt jāpamēģina vairāk ar JOSM

Ja kādi jautājumi par JOSM (un par iD jau arī), droši šajā listē jāprasa.

> - Reply to message -
> Subject: Re: [Talk-lv] Fona karšu nobīdes
> Date: Wed, 27 May 2020, 08:18
> From:  Rihards 
> To:  talk-lv@openstreetmap.org 
>> On 27.05.20 01:10, Ivars via Talk-lv wrote:
>>> Sveiki!
>>> Vai ir kaut kur informācija par to, kādas nobīdes ir pieejamajiem 
>>> fona aero/satfoto slāņiem Latvijā?
>>> Vai Esri aerofoto (kas taču ir 1:1 tas pats JS aerofoto) var 
>>> uzskatīt par visprecīzāko?
>>> Cik novēroju, Maxar uzņēmumi bieži ir vissvaigākie, bet tiem ir 
>>> pamatīga nobīde, ko tad jāmēģina pielīdzināt.
> 
>> ESRI šur tur ir labi foto, bet nobīde mēdz būt manāma.
>> Visprecīzākie tiešām līdz šim ir bijuši LVM publicētie LKS orto un 
>> LIDAR slāņi - https://www.lvmgeo.lv/dati -> servisi.
> 
>>> Un, ja, piemēram, esri ir precīzs vienā vietā, vai ir garantija, ka 
>>> 3km tālāk tas joprojām būs tikpat precīzs?
> 
>> Nē, pāris km tālāk var būt labi - bet var būt arī citādāka nobīde.
> 
>>> Gps trasēm arī ne vienmēr var uzticēties un daudzviet viņu ir par 
>>> maz (vai nav), lai pēc tām spriestu, cik metru pa labi, pa kreisi taka ir.
> 
>> GPX treisi ir manta, ja to ir daudz - tad pēc vidus var pieregulēt. 
>> Ja tuvumā ir kāds lielāks krustojums, tad pa abām asīm var.
> 
>>> Vai ir kaut kāds etalons, pēc kā var mēģināt vadīties, ja arī tas 
>>> nav pieejams kā fons, bet tā, lai var paskatīties uz to un uz 
>>> iekartēto osm un saprast, ir nobīde vai nav? Piemēram, Vzd kadastrā 
>>> redzamajām māju un ceļu kontūrām taču vajadzētu atbilst "zemes apstākļiem" 
>>> par 99.9%?
>>>
>>> P.s. Nebiju līdz šim ar citiem LV kartētājiem kontaktējis - vai šis 
>>> ir primārais saziņas veids vai ir kāds slepens forums, par ko nezinu, arī?
>>> (Forum.osm.org users:lv zinu)
> 
>> Ir primārais - bet varbūt Raitim pirms daudziem gadiem bija taisnība, 
>> un vajag kaut ko normāliem cilvēkiem vieglāk pieejamu - kā forumu :)
> 
>>> Ivars--
>> Rihards
--
 Rihards

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


Re: [Talk-se] Talk-se Digest, Vol 145, Issue 18

2020-05-28 Thread Per Geijer
Hej Tomas,

Det är lätt att sitta framför en dator och tro att stående format är helt 
kokobello, men majoriteten av konsumtionen av film på nätet sker på 
mobiltelefoner. För att kunna göra det bästa valet för just det här projektet 
måste man veta mer om målgruppen, men utan att veta någonting om den så är 
stående format sannolikt bäst.

Hälsningar från en gamling med barn, som jobbar professionellt med filmer till 
bl a Youtube.
//Per

> 28 maj 2020 kl. 13:00 skrev talk-se-requ...@openstreetmap.org:
> 
> Send Talk-se mailing list submissions to
>   talk-se@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/talk-se
> or, via email, send a message with subject or body 'help' to
>   talk-se-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   talk-se-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-se digest..."
> 
> 
> Today's Topics:
> 
>   1. Förfrågan från Wikimedia Sverige (Karl Wettin)
>   2. Re:  Förfrågan från Wikimedia Sverige (Tomas Marklund)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 27 May 2020 15:35:46 +0200
> From: Karl Wettin 
> To: "talk-se@openstreetmap.org e-postlista"
>   
> Subject: [Talk-se] Förfrågan från Wikimedia Sverige
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Wikimedia Sverige undrar om vi kan tänka oss att spela in en liten film
> (max 55 sekunder lång) i stående format på en telefon där man berättar lite
> om varför OSM är bra. Filmen måste vara CC-BY (eller bättre) då den kommer
> distribueras av dem.
> 
> Är det någon här som kan tänka sig att spela in och vara huvudpersonen i
> denna film? Som anställd av Wikimedia Sverige upplever jag det som att jag
> sitter på lite för många stolar och har lite för många hattar på mig för
> att vara den som är med på denna film och uttrycker sina åsikter.
> 
> Jag tycker det är rimligt att den som spelar in filmen har fullt mandat att
> föra fram sina subjektiva åsikter. Samtidigt är det juste om vi,
> gemenskapen, tillsammans först kan prata lite om vad det är som gör OSM bra
> för att ge lite vägledande tankar. Dock är det väldigt svårt att summera
> det på 55 sekunder.
> 
> Eftersom de flesta som kommer se filmen inte vet hur OSM skiljer sig från
> tex en tryckt karta på ett papper så tror jag det är bra att fokusera på
> att det handlar om geografisk rådata och att kartan bara är ett av många
> tänkbara resultat av att arbeta med denna data. Den kan användas till att
> skapa en reseplaneringsmjukvara. En biodlare kan ställa en GIS-fråga för
> att leta upp lämpliga innergårdar i stadsmiljö nära kolonilotter för att
> ställa ut kupor. Din bil skulle kunna rekommendera dig att parkera runt
> hörnet så solen smälter frosten på fönsterrutan åt dig på morgonen. Att HOT
> på riktigt räddat liv när gemenskapen kommit samman och skapat kartor åt
> räddningsarbetare i katastrofområden.
> 
> Är det någon som känner sig manad att ta denna pucken? Jag borde egentligen
> inte skriva det, men vill ingen så kan jag göra det.
> 
> Värt att nämna i detta mejl är att Wikimedia Sverige är de som för många år
> sedan ursprungligen sponsrat OpenStreetMap Sverige med server, och nu i
> veckorna med nya hårddiskar till denna då de gamla brunnit upp. Så det är
> en liten gentjänst från oss till dem att göra det här.
> 
> 
> Kalle
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 2
> Date: Wed, 27 May 2020 16:01:37 +0200
> From: Tomas Marklund 
> To: OpenStreetMap Sverige mailinglista 
> Subject: Re: [Talk-se]  Förfrågan från Wikimedia Sverige
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Stående format? Suck.. Skicka tillbaka den här till dem :)
> 
> https://youtu.be/f2picMQC-9E
> 
> /Tomas
> 
> Den ons 27 maj 2020 kl 15:37 skrev Karl Wettin :
> 
>> Wikimedia Sverige undrar om vi kan tänka oss att spela in en liten film
>> (max 55 sekunder lång) i stående format på en telefon där man berättar lite
>> om varför OSM är bra. Filmen måste vara CC-BY (eller bättre) då den kommer
>> distribueras av dem.
>> 
>> Är det någon här som kan tänka sig att spela in och vara huvudpersonen i
>> denna film? Som anställd av Wikimedia Sverige upplever jag det som att jag
>> sitter på lite för många stolar och har lite för många hattar på mig för
>> att vara den som är med på denna film och uttrycker sina åsikter.
>> 
>> Jag tycker det är rimligt att den som spelar in filmen har fullt mandat
>> att föra fram sina subjektiva åsikter. Samtidigt är det juste om vi,
>> gemenskapen, tillsammans först kan prata lite om vad det är som gör OSM bra
>> för att ge lite vägledande 

Re: [Talk-it] [Import] civici Bergamo

2020-05-28 Thread Andrea Musuruane
Li hai corretti tu?

Ciao,

Andrea


On Thu, May 28, 2020 at 12:04 PM Cascafico Giovanni 
wrote:

> Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.
>
> Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha
> scritto:
>
>> Ciao a tutti,
>> ho provato a documentare questo import sulla wiki:
>>
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
>>
>> Se concordate, per procedere e mantenere i dati importati in OSM, bisogna
>> fare tanta QA. I casi che ho trovato sono elencati nella wiki. Non escludo
>> che lavorandoci più attivamente sopra, se ne scoprano altri.
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
>> wrote:
>>
>>> Ciao,
>>>
>>> On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni 
>>> wrote:
>>>
 Ho standardizzato i civici, rimuovendo la barra e portando a maiusolo
 l'esponente.

>>>
>>> Perché in maiuscolo?
>>>
>>> Prima di continuare (chiunque), possiamo almeno scrivere una pagina di
>>> import che descrivere le cose fatte/da fare?
>>>
>>> Lato mio posso: a) fare uno script di conversione con ogr2osm b)
>>> suggerire di usare come modello la pagina di import che avevo fatto per
>>> Biella
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
>>>
>>> Grazie,
>>>
>>> Andrea
>>>
>>> ___
>> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [Import] civici Bergamo

2020-05-28 Thread Cascafico Giovanni
Subalterni numerici dovrebbero essere risolti. Vedi wiki e umap linkata.

Il mer 27 mag 2020, 11:08 Andrea Musuruane  ha scritto:

> Ciao a tutti,
> ho provato a documentare questo import sulla wiki:
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Bergamo_address_import
>
> Se concordate, per procedere e mantenere i dati importati in OSM, bisogna
> fare tanta QA. I casi che ho trovato sono elencati nella wiki. Non escludo
> che lavorandoci più attivamente sopra, se ne scoprano altri.
>
> Ciao,
>
> Andrea
>
>
> On Mon, May 18, 2020 at 1:08 PM Andrea Musuruane 
> wrote:
>
>> Ciao,
>>
>> On Mon, May 18, 2020 at 1:04 PM Cascafico Giovanni 
>> wrote:
>>
>>> Ho standardizzato i civici, rimuovendo la barra e portando a maiusolo
>>> l'esponente.
>>>
>>
>> Perché in maiuscolo?
>>
>> Prima di continuare (chiunque), possiamo almeno scrivere una pagina di
>> import che descrivere le cose fatte/da fare?
>>
>> Lato mio posso: a) fare uno script di conversione con ogr2osm b)
>> suggerire di usare come modello la pagina di import che avevo fatto per
>> Biella
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/Provincia_di_Biella/Addresses
>>
>> Grazie,
>>
>> Andrea
>>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] Tagging/suppression d'un passage dangereux

2020-05-28 Thread Marc M.
Bonjour,

Le 27.05.20 à 18:00, André Maroneze a écrit :
> Est-ce que "access=no" serait valide ici

cela correspondrait à un panneau "interdit y compris piéton"
qui ne semble pas être présent.

> semble que traverser une départementale à pied en dehors d'un passage
> piéton soit interdit ?

seulement s'il y a un passage piéton à moins de 50m
https://fr.wikipedia.org/wiki/Passage_pi%C3%A9ton#R%C3%A9glementation

> faudrait-il supprimer ce chemin

non, il existe :)

> https://www.openstreetmap.org/way/81972368
> Merci pour vos avis et suggestions,

rajouter les 3 passages piétons non marqué
https://www.openstreetmap.org/node/5313575069
https://www.openstreetmap.org/node/5313575067
https://www.openstreetmap.org/node/955065661
highway=crossing crossing=unmarked
ainsi un routage peux tenir compte du danger.

changer le tag note (info à destination d'un contributeur)
en description (info à destination de l'utilisateur final)

supprimer le fixme

rajouter surface (là aussi le routage peux en tenir compte)

Cordialement,
Marc

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


[OSM-talk-fr] osm11 osm12 osm13 indisponible en ipv4 (ipv6 ok) : impact bano, cadastre, cyclosm, download, osmose (maj)

2020-05-28 Thread Marc M.
Bonjour,

depuis hier environ 20h30, ces 3 serveurs sont injoignable en ipv4.
j'ai envoyé un message à l'hébergeur et j'ai modifiés quelques bricoles
pour restaurer ce qui pouvait l'être partiellement dans l'état actuel.

Cordialement,
Marc

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


Re: [OSM-talk-fr] Collecteur de mégots ?

2020-05-28 Thread Yves P.
>> Donc nudge=yes ?
> Ce tag n'existe pas encore dans la base OSM.

Mais il existe la catégorie dans Wikimedia : Nudge 

Il existe aussi des nudge pour coller ses chewing-gum :
Besançon et ses bornes de propretée 

Lilles et ses plaques à chewing-gum, poubelles à cible 

Rodez 

Marseille 

Valence 


amenity=waste_basket
waste=chewing_gum

2 dans OSM : https://overpass-turbo.eu/s/Ute


Et des collecteurs  pour les recycler : 
File:Gumdrop collector, Caldicot.jpg 


Et aussi en Corse des collecteurs mixtes  de 
mégots et de chewing-gum…

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


Re: [Talk-it] [Talk-it-cai] Mappare il numero del sentiero sui cartelli segnaletici del CAI

2020-05-28 Thread Gabriele Sani via Talk-it
Capisco cosa intendi ma mi sembra ridondante e piu' complicato da mantenere 
della relazione d'appartenenza. E' vero che un utente al momento, guardando 
come sono mappati i segnaposti "doppi", non puo' inferire a che sentiero 
corrisponde una specifica localita' indicata in destination, ma puo' capirlo 
incrociando i dati che ha.

Nel caso che hai portato dell'immagine
https://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/20200517-costa_del_palio-42.jpg/800px-20200517-costa_del_palio-42.jpg
guardando le relazioni a cui apparterrebbe il segnavia (571 e 577) capisco 
subito che l'indicazione per Brumano non puo' essere relativa al 571 (dato che 
da li il percorso non passa) e quindi sra' relativa al 577.

Gabriele Sani

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, May 27, 2020 11:38 PM, Andrea Mazzoleni  
wrote:

> On Wed, May 27, 2020 at 8:23 PM Ivo Reano  wrote:
>
>> Il punto è che il cartello sta dando una precisa informazione, ma se il palo 
>> compare in più relazioni, questa informazione non è mappata.
>
>> In che senso "non è mappata"?
>
> Guarda questo cartello: 
> https://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/20200517-costa_del_palio-42.jpg/800px-20200517-costa_del_palio-42.jpg
>
> Chiaramente indica quale sentiero numerico prendere, 571 o 577, per ciascuna 
> località.
>
> Il mio scopo è mappare la stessa informazione nel guidepost. Se aggiungo il 
> guidepost ad entrambe le relazioni dei sentieri 571 e 577 non sto facendo 
> questo. Bisognerebbe poter aggiungere il singolo cartello alla relazione, e 
> non il palo con tutti i cartelli.
>
> La cosa più semplice e corretta mi sembra invece di mettere il numero del 
> sentiero, così come è scritto nel cartello, nel campo "destination=", 
> esattamente come si fa con le località.
>
> Ciao,
> Andrea
>
>>___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-es] Demarcaciones sanitarias

2020-05-28 Thread David Marín Carreño
Mi pregunta es por qué se están proponiendo distintas etiquetas de nivel
(healthcare_level, environment_level) en lugar de la ya existente
admin_level.

Esta etiqueta ya está siendo usada por boundary=religious_administration
tanto en Polonia como Alemania.

--
David Marín Carreño 



El mié., 27 may. 2020 a las 20:20, hugo () escribió:

> Respecto a lo de proponerlo sin duda es el camino, pero antes queríamos
> tenerlo un poquito más organizado. Para ello he creado esta página:
> https://wiki.openstreetmap.org/wiki/ES:Otros_L%C3%ADmites.
>
> Mi idea es que podamos editar en esta página (quién quiera) algunas ideas
> tanto de tags, como de fuentes (mayoritariamente son de CyL ahora) antes de
> elaborar una propuesta formal (como aquí se describe
> https://wiki.openstreetmap.org/wiki/Proposal_process). Si alguien no sabe
> editar en wikipedia o no tiene cuenta o lo que sea, puede mandar un correo
> aquí para que se agregue el contenido.
>
> Saludos
>
> El mar, 26 de may de 2020 a las 11:25, Alejandro Moreno 
> escribió:
>
> Yo no puedo aportar mucho al etiquetado pero os dejo un par de propuestas.
> La primera es proponerlo en la lista de etiquetado global ya que ahí pueden
> proponer otras opciones de etiquetado y la segunda es documentar en la wiki
> la solución que finalmente se use, de manera que quede reflejado las
> etiquetas a usar como documentación para el futuro.
>
> Un saludo.
>
> El lun., 25 may. 2020 a las 12:04, Jorge Sanz Sanfructuoso (<
> sanc...@gmail.com>) escribió:
>
>> Buenas.
>>
>> A lo mejor se puede hacer igual que en las zonas administrativas que se
>> añade en la relación un admin_center. Añadir en estas zonas algo parecido
>> con el centro de salud principal de la demarcación sanitaria.
>>
>> Un saludos.
>>
>>
>> El lun., 25 may. 2020 a las 2:43, Diego Cruz ()
>> escribió:
>>
>>> Hola, Rafael:
>>>
>>> Muchas gracias por tu respuesta.
>>>
>>> Un compañero me ha advertido de que el único país donde estaba mapeado
>>> esto era el Congo, y allí utilizaban "health". Sin embargo, yo diría que
>>> "health" en inglés es más bien la salud de uno mismo, mientras que
>>> "healthcare" se refiere a la sanidad o atención sanitaria. Por eso había
>>> optado por esto último (además de que está el grupo de etiquetas
>>> "healthcare").
>>>
>>> Acabo de subir la primera zona básica de salud (rural) como ensayo
>>> piloto (changeset #85697721) y al hacerlo me he dado cuenta de algunos
>>> fallos en lo que había propuesto, como el tema de la referencia que
>>> mencionas. Coincido en que es una tontería inventarse "health_ref", así que
>>> había puesto ref:healthcare, pero si basta con "ref" a secas, por mí no hay
>>> problema, lo cambio. No soy muy experto en el tema de las referencias.
>>>
>>> Es decir, me parece perfecto lo que dices (*boundary=healthcare +
>>> healthcare_level=X*) con ref a secas, pero cambiando health por
>>> healthcare (aunque se esté usando ya health, yo creo que si se propone a
>>> nivel mundial la gente de habla inglesa no va a aceptar health, aunque todo
>>> es cuestión de ver qué pasa).
>>>
>>> En cuanto al etiquetado de los centros, teniendo en cuenta el conflicto
>>> existente entre amenity=x y healthcare=x que han mencionado algunos
>>> compañeros, he optado por poner las dos, y que se borre automáticamente
>>> después la que quede en desuso.
>>>
>>> También he visto que para los consultorios de atención primaria sería
>>> "doctors" y no "doctor" como había puesto.
>>>
>>> Un saludo
>>> Diego
>>>
>>>
>>> El lun., 25 may. 2020 a las 1:59, Rafael Avila Coya (<
>>> ravilac...@gmail.com>) escribió:
>>>
 Hola, Diego:

 En la República Dem. del Congo se están mapeando las zonas sanitarias
 del país. Hace unos años atrás colaboré con Claire Halleux de la comunidad
 local congolesa sobre el tagging para esas entidades, pues no teníamos
 referencia en otros países.

 Por consistencia con los datos que ya hay, estaría bien seguir ese
 esquema, y quizás luego proponerlo para la wiki global para que en otros
 países se siga también este mismo esquema, y no que haya varios esquemas
 diferentes para lo mismo.

 La sección en la que se explica es esta:
 https://wiki.openstreetmap.org/wiki/Congo-Kinshasa/Zones_de_sant%C3%A9#Trouver_les_bons_tags

 Basicamente es boundary=health + health_level=X

 En cuanto a ref, podría usarse la etiqueta ref=* que ya existe en la
 wiki, en vez de crear una health_ref.

 Saludos,

 Rafael.
 O 24/05/20 ás 21:54, Diego Cruz escribiu:

 Hola a todos:

 En el grupo de Castilla y León hemos estado hablando sobre mapear una
 serie de límites territoriales y por iniciativa personal he propuesto
 empezar con los distritos sanitarios. Os dejo un esquema de mi propuesta
 para los usuarios de Castilla y León y por si pudiese aprovecharse en otras
 autonomías.

 El territorio podría dividirse utilizando la etiqueta