Re: [Talk-at] minderwertige Importe

[andreas wecer]

Am Do., 11. Juli 2019 um 22:21 Uhr schrieb Michael Reichert <
osm...@michreichert.de>:

> Das Kriterium ist auf den ersten Blick machbar. Ich habe mir die
> Änderungssätze bislang noch nicht angeschaut, daher die etwas dumme
> Rückfrage meinerseits: Was tun, wenn ein v1-Node Mitglied eines
> hochgeladenen Ways ist, der geändert worden ist (also jetzt v > 1), oder
> später für einen Way verwendet worden ist?
>

Wenn die Daten inzwischen von jemand anderem bearbeitet wurden, kann das
meiner Meinung nach in den meisten Fällen als "kontrolliert" oder
"korrigiert" gewertet werden. Im allerschlimmsten Fall hat es sich
zumindest einmal jemand angesehen, solange nicht jemand anderes mit einem
großflächigen, mechanischen Edit darüber gefahren ist, aber davon ist
nichts bekannt.

> * Changesets mit dem Beginn "Fehlende oder neue Adressen*"
>
> Ab wann (Zeitpunkt) ist dieses Kriterium anzuwenden?


Das dürfte das erste Changeset außerhalb seiner Kernregion sein, ab wo er
nur noch großflächig importiert hat:
https://www.openstreetmap.org/changeset/70645289

also im Grunde geht es um diese Nodes:
node["at_bev:addr_date"="2019-04-01"](user:"addresshistory*org")(newer:"2019-05-27T00:00:00Z");out;

Die Changesets, wo er existierende Daten bearbeitet und großflächig
Adressen gelöscht hat, sind großteils schon wieder rückgängig gemacht.

LG
  Andreas
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Mapping rail trails

[stevea]

Yes, thank you, Minh.  I forgot to mention the importance of using the 
cycle_network tag, as it can both disambiguate routes which might be 
named/numbered the same or similarly AND coalesce them together into a coherent 
collection of routes which are clearly "all members of a single network."

As our https://wiki.osm.org/wiki/Key:cycle_network wiki says, "Ideally, all 
route relations in a single cycleway network should be tagged with the same 
cycle_network=* value."  That is (rather simply) what it does.

I'd say it is typical for "government" (national-level, as in USBRS / ncn, 
state / rcn as well as city-county / lcn) routes to be collected together into 
a single cycle_network, all having the same value, like US:CA:SF for all of San 
Francisco's bicycle routes.  Whether RAIL-TRAIL routes are collected together 
into cycle_networks isn't something I know a whole lot about right now, but I 
am curious for more real-world data to emerge about that.  Here?  Sure.  In the 
map? (as in actual OSM cycle_network tagging)?  Yes, that works, too.  Try 
clicking that link above, then its "taginfo" link to get a flavor for how this 
tag is used.

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

Re: [OSM-ja] 農水省の筆ポリゴンのインポート許可がおりました

[Satoshi IIDA]

いいだです。

ID付きのデータが公開された、ということで、対象のデータについて調査を行っています。
東京の調布市と町田市について、ogr2osmを使って変換したサンプルを作成しました。
（大丈夫だとは思いますが、これらのファイルをOSMにアップロードしないようお願いします。。。）

もし、自分の気になる地域がありましたらご連絡ください。
変換して、アップロードします。
https://github.com/osmfj/farmland_fude_mapping/tree/master/sample

データ品質として気になったことは、GithubのIssueにまとめています。
https://github.com/osmfj/farmland_fude_mapping/issues/2#issuecomment-510321554

個人的には、市町村単位よりも細かい単位（例えば丁目やメッシュなど）で作業単位を分割する必要があると思っているのですが、
どういう単位で区切ったらよいのか、
また（すみません、最近めっきり技術から離れていることもあり）いまの僕のスキルで正しく作業できるものか、けっこう不安に感じています。

ライセンスの互換性についての質問は、昨晩Imports MLに投稿したところです。
いまのところレスポンス特にないので、少し待ちです。


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] nettoyage du centre de la France

[marc marc]

Bonsoir,

Personne ne s'y étant opposé, j'ai fais le nettoyage.

Par contre j'ai un problème de position.
la version #1 sur osm parle d'un rayon de 533km
wikipedia parle d'une position situé 1km + vers l'ouest
et d'un rayon de 543,7 km
Et pour ma part, empiriquement, depuis une position 21m + à l'est,
j'ai un rayon de 542,3km vers les 3 points décrit par wikipedia.

quelqu'un connaît un outil pour charger la frontière terrestre
d'osm et refaire le recherche ?

en attendant je n'ai pas bougé le nœud mais j'ai supprimé l'info "de 
533km" qui est contredit par ces 3 nœuds 
https://www.openstreetmap.org/node/1657321848 
https://www.openstreetmap.org/node/1278645901 
https://www.openstreetmap.org/node/323548413

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

Re: [Talk-us] Mapping rail trails

[Minh Nguyen via Talk-us]

On 2019-07-11 17:27, Greg Troxel wrote:

Thanks for the nice summary.  I have one minor issue to raise a question
about:

stevea  writes:


As for rail trails, very nice work, Richard!  Rail trails are usually
classified as local (lcn) if they are for cyclists, although some are
sponsored at a state-level: these are properly tagged rcn (regional
generally means "state-level" in the USA).  I don't know this for sure
(Minh?) but I might imagine that the C Canal Trail over and above
the USBR 50 relation might be properly tagged rcn instead of lcn.
Such decisions are best determined with more-local consensus by
Contributors who are familiar with the local / state statutes which
define the route.  The Bicycle_Networks wiki describe (MUTCD-standard)
signage for NUMBERED routes which disambiguate the network-level tag
that should be used.  For routes which happen to be signed
on-the-ground as non-governmental (non-MUTCD-standard signage), please
consider these on a case-by-case basis, starting (as Richard did) at
the local (lcn) level.  If network=rcn is actually a better value,
this is likely to emerge with strong consensus at a more-local (state)
level within OSM.


The notion of state sponsorship is interesting, and there is the aspect
of a state bicycle route number, akin to a state numbered highway.  I
can certainly see that being rcn.  Then there is the aspect that in MA,
most things called "rail trails" end up getting built with state funds,
and built to state construction standards, both avoiding the towns
having to say and making the resulting trail much more costly (but nicer
in some ways).  These trails tend to have names, like "Nashua River Rail
Trail", "Assabet River Rail Trail", "Bruce Freeman Rail Trail", but they
don't have a "MA Bicycle 29" designation, or if so nobody knows that.

Most of them go over fairly short distances; the Nashua River one is
about 12 miles and is in the towns of Ayer, Groton, Pepperell, MA and a
bit in Nashua, NH.  To me, that feels local in scope rather than
statewide, so I'd want to see it as lcn.  The fact that it was funded
with state rather than local money doesn't seem important.  (Actually,
state money pays for local roads in complicated scheme.)

Now, if the Central Mass Rail Trail were somehow complete in a Cambridge
to Northhampton sort of way, or even half of that, it's obviously rcn,
regardless of who organizes it.

This gets fuzzy.  Perhaps, in a US-centric northest-centric way, it
feels like rcn is 100 km.

I'm not sure this ended up being useful.  I think I more or less agree
with where I think you ended up, saying that other than federal and
state numbered routes, all routes are lcn, unless there is really clear
local consensus that they are very important and of state-level scope,
in which case they can be promoted to rcn.


I think this speaks to the utility of the cycle_network [1] and operator 
tags. The network=lcn/rcn/ncn/icn tagging scheme may've sufficed in the 
early days in the UK, but increasingly more nuance is needed on both 
sides of the pond.


As with the network tag on bus routes, what's important for both network 
and cycle_network is that the route is intended to form part of a 
coherent *network* (almost like a brand, but not quite). A given route's 
actual length, connectivity, build quality, or ownership on its own is 
perhaps less important, but consistent signage or ownership is how an 
organization might establish a set of routes as a network.


Long ago, Ohio's transportation department set up a state system of 
lettered bicycle routes along rural roads, which no practically no one 
knows about. But local bike advocacy groups also coordinated on a system 
of numbered routes over state- and county-maintained trails.


Over time, Dayton-area counties took up the task of signposting the 
unofficial numeric routes with the same kind of signage as the official 
statewide system. Then adjacent counties up and down the state followed 
suit, to the point that the numbered routes are the state system for all 
intents and purposes. A few years ago, all the routes in the state were 
renumbered, something that has happened many times to state road route 
networks. [2] But IIRC it was carried out by trail managers and 
coordinated by regional planning commissions rather than the state.


The numeric network includes some spur routes that are shorter than many 
city-maintained local routes but bear state route signage, such as route 
3E. [3] The alphabetic and numeric routes alike are tagged with the same 
cycle_network=US:OH, though the operator tag can be used to distinguish 
if necessary. It's all a bit chaotic, but hey, that's reality.


[1] https://wiki.openstreetmap.org/wiki/Key:cycle_network
[2] 
https://en.wikipedia.org/wiki/Category:Highway_renumbering_in_the_United_States

[3] https://www.openstreetmap.org/way/128492582

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [Talk-us] Mapping rail trails

[stevea]

Phil!

I know it seems "like it just makes sense" to combine Maryland and DC 
relations, but there are rather deliberate reasons to keep these separate.  One 
is state-level, the other is federal-level (is one), but the "state at a time 
for route relations" is a fairly well-established method of tossing things into 
buckets.  We do it with bike routes, motorways and more.

I think what Richard might have been describing is what Greg Troxel is trying 
to get at now:  where we say "state sponsorship" of a rail trail begins and 
ends.

Greg:

Especially when MUTCD M1-8 signage is used on the route, network=rcn for state 
routes seems clear (we agree, you and I, and the wiki for at least five or six 
years).  The [Nashua River Trail, Assabet River Rail Trail, Bruce Freeman Rail 
Trail...] examples you offer do "feel more local" to me as well.  I am 
thousands of miles away on the other coast, so I only offer what I see in a 
wider and longer-term national scope about how this sort of tagging has evolved 
in the last decade or so.

I'd dislike offering a "carte blanche" (too easy) sort of heuristic like "under 
100 km" when what we're trying to capture here in distinguishing at the 
local/lcn and regional-state/rcn "levels" is (at least) two fold:

1)  A "level of government" which rather handily maps "rcn=state(provincial)" 
and "lcn=county/city" in USA and even North America

2)  A kind of way of thinking about the "greater continent-wide notion of how 
we think about bicycle routes" (here in North America).

Sometimes, it can and does make sense for a rail trail to be an rcn even as it 
has started out as an lcn.  I believe that "more local" (people in the state or 
region) have more to say about this than any single person does, though I do 
think it is helpful to keep in mind the evolution of these tags in North 
America over the last 15 years.  It hasn't been orderly, but it is feeling more 
orderly.  I think if we are careful in how we come to agreement about what it 
means to "promote to rcn" (and we clearly express those rules/methods of 
determination) in our wiki, with consensus, we'll continue to be doing the best 
job of this that we can.

Sometimes things ARE fuzzy.  Sometimes, with a little discussion, we can knock 
a bit of fuzz right off.

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

[Talk-us] Whole-US Garmin Map update - 2019-07-09

[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/2019-07-09

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2019-07-09/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/2019-07-09

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] Mapping rail trails

[Greg Troxel]

Thanks for the nice summary.  I have one minor issue to raise a question
about:

stevea  writes:

> As for rail trails, very nice work, Richard!  Rail trails are usually
> classified as local (lcn) if they are for cyclists, although some are
> sponsored at a state-level: these are properly tagged rcn (regional
> generally means "state-level" in the USA).  I don't know this for sure
> (Minh?) but I might imagine that the C Canal Trail over and above
> the USBR 50 relation might be properly tagged rcn instead of lcn.
> Such decisions are best determined with more-local consensus by
> Contributors who are familiar with the local / state statutes which
> define the route.  The Bicycle_Networks wiki describe (MUTCD-standard)
> signage for NUMBERED routes which disambiguate the network-level tag
> that should be used.  For routes which happen to be signed
> on-the-ground as non-governmental (non-MUTCD-standard signage), please
> consider these on a case-by-case basis, starting (as Richard did) at
> the local (lcn) level.  If network=rcn is actually a better value,
> this is likely to emerge with strong consensus at a more-local (state)
> level within OSM.

The notion of state sponsorship is interesting, and there is the aspect
of a state bicycle route number, akin to a state numbered highway.  I
can certainly see that being rcn.  Then there is the aspect that in MA,
most things called "rail trails" end up getting built with state funds,
and built to state construction standards, both avoiding the towns
having to say and making the resulting trail much more costly (but nicer
in some ways).  These trails tend to have names, like "Nashua River Rail
Trail", "Assabet River Rail Trail", "Bruce Freeman Rail Trail", but they
don't have a "MA Bicycle 29" designation, or if so nobody knows that.

Most of them go over fairly short distances; the Nashua River one is
about 12 miles and is in the towns of Ayer, Groton, Pepperell, MA and a
bit in Nashua, NH.  To me, that feels local in scope rather than
statewide, so I'd want to see it as lcn.  The fact that it was funded
with state rather than local money doesn't seem important.  (Actually,
state money pays for local roads in complicated scheme.)

Now, if the Central Mass Rail Trail were somehow complete in a Cambridge
to Northhampton sort of way, or even half of that, it's obviously rcn,
regardless of who organizes it.

This gets fuzzy.  Perhaps, in a US-centric northest-centric way, it
feels like rcn is 100 km.

I'm not sure this ended up being useful.  I think I more or less agree
with where I think you ended up, saying that other than federal and
state numbered routes, all routes are lcn, unless there is really clear
local consensus that they are very important and of state-level scope,
in which case they can be promoted to rcn.


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

Re: [Talk-GB] UK coastline data

[Edward Catmur via Talk-GB]

Tricky - it appears to be a rule that all the famous sea caves are
accessible by foot at low tide (there's probably a geological reason, like
why sea cliffs tend to have a ledge below exposed at low tide). That said,
some sea arches have inward-sloping sides - e.g. Stair Hole
https://www.openstreetmap.org/node/2128418334 on the 1:25000 the HWM and
LWM both appear to follow the outer edge of the arch above while the
interior is rendered with the cave/cave entrance symbol.

It's an interesting question how to map sea caves and natural arches - all
I've looked at so far have the coastline running along the outer edge of
the land above, but OTOH you have natural arches like Rainbow Bridge
https://www.openstreetmap.org/way/569676595 mapped as an area natural=rock
with Lake Powell running uninterrupted underneath it; and Natural Bridge
https://www.openstreetmap.org/node/4325038750 is mapped as two cliffs, not
intersecting the creek or path beneath.

On Thu, Jul 11, 2019 at 9:56 PM Colin Smale  wrote:

> Good point. Do you know of one? Let's have a look at how the OS deal with
> it.
>
>
>
> On 2019-07-11 22:52, Edward Catmur wrote:
>
> On Thu, Jul 11, 2019 at 9:19 PM Colin Smale  wrote:
>
>> * Where the coastline is essentially vertical (harbour walls, steep
>> cliffs) MHWS and MLWS can coincide in OS data (sharing nodes but not ways),
>> but of course low water can never be landward of high water.
>>
> Is this necessarily the case? Couldn't an overhang result in a low water
> landward of high water? Consider e.g. a sea cave that is flooded at high
> tide.
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-at] Wie weiter mit dem Troll?

[Norbert Wenzel]

On 11.07.19 15:04, ScubbX wrote:

Wer wäre bei einem Listenproblem der nächsthöhere Ansprechpartner?
Ist es die DWG? Ist Frederik R. dabei offiziell(er) eingebunden?


Vermutlich wäre irgendwann die DWG bzw. die Foundation zuständig. Die 
betreiben diese Listen glaube ich offiziell.


Ich habe mich mit Frederik einmal beraten, aber afaik sind die Listen da 
relativ autonom in ihren Moderationsentscheidungen.


lg,
Norbert

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

Re: [Talk-at] minderwertige Importe

[Robert Kaiser]

Johann Haag schrieb:

Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten
anpassen. Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man
in der Lage die Plausibilität von Adressen zu prüfen. Die Behauptung dass
importierte Adressen vielfach in der Landschaft liegen, kann man daher erst
nach Vorlage eines aktuellen Luftbildes prüfen.


Falsch. Der Gold-Standard von OpenStreetMap ist (und so weit ich weiß 
war immer), was auch immer "am Boden", also wenn man direkt vor Ort ist, 
nachvollziehbar ist. Luftbilder und irgendwelche Datensätze, ob von 
Ämtern oder sonstwo, sind möglicherweise Hilfen, aber nie irgendwelche 
Standards für OSM. Wirklich korrekt machen kannst du es nur, wenn du vor 
Ort warst und dort die Gegebenheiten geprüft hast. Weder mit einem 
Luftbild noch mit BEV-Datensätzen jeglicher Art kannst du die Qualität 
erreichen, die du mit einer Erhebung vor Ort bekommst.
Und so weit ich weiß, war der Adress-Helper auch immer nur als Hilfe für 
einzelne Einträge mit Vor-Ort-Wissen gedacht und nicht als Basis für 
große Importe. Die Erfahrung im Projekt zeigt, dass Importe größerer Art 
meist die Community schädigen, und das dürfte sich auch hier wieder 
zeigen, man könnte möglicherweise sogar unterstellen, dass es gezielt 
darum geht, diesen Effekt zu erzielen. So weit will ich mal nicht gehen, 
aber das Ergebnis ist trotzdem ziemlich das gleiche. Also am besten von 
Importen absehen und vor Ort erheben, dann sind wir wahrscheinlich alle 
glücklicher.


Grüße,
Robert


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

[OSM-talk-fr] Spécialité médicale : soins cliniques en addictologie

[Christian Rogel]

En cherchant à cartographier une clinique spécialisée dans les soins pour les
gens dans la dépendance de l’alcool et des drogues, je n’ai pas trouvé 
d’indication
claire dans le wiki anglais ou français.

Au passage, je signale la remarquable page 
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un_(sant%C3%A9)
(titre bizarre) qui est très complète, et signale les CSAPA qui ne semblent pas
concerner les soins cliniques, mais, l’accompagnement des dépendants (qui inclut
pourtant la délivrance de médicaments).
Le seul CSAPA de ma ville est dans un autre quartier et est dénommé « centre 
d’addictologie".


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

Re: [OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[Kathleen Lu via legal-talk]

There is fairly limited case law on what constitutes "substantial
investment" under the database law. Here is an article discussing a couple
of cases where significant investment was rejected, and one where it was
accepted (sadly all in the context of sports, not geodata) -
https://www.lexology.com/library/detail.aspx?g=ddc63c34-a49f-4876-86d5-aaec83d65ed1
Best,
Kathleen



On Thu, Jul 11, 2019 at 1:48 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. Jul 2019, at 20:23, Kathleen Lu  wrote:
> >
> > "Substantial investment" may not be a black and white standard, but it
> is a meaningful one. I hypothesize that Tesco would have difficulty proving
> "a substantial investment in either the obtaining, verification or
> presentation of the contents." (Note that investment in creating/setting
> the hours does not count.)
>
>
> It may have come along as sarcasm the way I have written it, but the idea
> is actually appealing: significant investment wrt the database could
> eventually be dismissed for those databases, which are more or less the
> result of some related operation/work, a byproduct, rather than being set
> up to gather and analyze data without being required in the operation. The
> investment would be the operation, while the db as a byproduct would be
> almost “free”. The OpenStreetMap database would still be protected under
> perspective, but a lot of databases would not be protected automatically
> any more.
>
> The maps the GIS department releases are definitely requiring a
> significant investment, but the lists of streets a municipality releases
> would probably not be covered by the sui generis rule because there is not
> much specific investment behind such a compilation, it is a byproduct of
> their operation as a public administration. Or the post code lists of the
> postal service: the effort is not specifically put into the db, they only
> have to print what they already know from planning and organizing the
> postal service.
>
> Is there already case law with examples where a claimed significant
> investment has been rejected? I would suspect that almost any database
> could be seen as having required a lot of investment for the creation and
> updates, or not, according to how you put it.
>
> From a practical point of view I agree I would not be worried about
> copying opening hours (or addresses, or phone numbers) from a retail
> company’s website, e.g. Tesco. It’s more likely they would pay you for this
> than sue you.
>
> Cheers Martin
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-GB] UK coastline data

[Colin Smale]

On 2019-07-11 22:45, Borbus wrote:

> On Thu, Jul 11, 2019 at 9:19 PM Colin Smale  wrote:
>> * Coastal admin boundaries (the "Extent of the Realm") are usually MLWS,
>> but there are such things as "seaward extensions" which extend the
>> "realm" further into the water. Check out for example Brighton Marina,
>> Torbay, City of Bristol.
> 
> I have noticed the boundaries often correspond with MLW. I have tried to
> leave the boundaries alone even when they overlap with the MLW because I
> thought combining them might be confusing.

Combining them might actually be the right thing to do. As a matter of
law the local government jurisdiction extends to MLWS (except where
explicitly otherwise defined) so it should be a question of choosing the
best data, probably the data from the most recent survey. Don't forget
sandbanks and other areas that fall dry at low water - these are also
marked by the OS with MLWS and are therefore admin boundaries. 

>> * Where the "coastline" crosses the mouth of a river or estuary, there
>> has been lots of discussion about this in the past, as usual without a
>> clear definitive verdict. The OS data will take you upstream to the
>> tidal limit of rivers, which sometimes gives results which some people
>> find undesirable. Example: River Dart in Devon.
> 
> Yes, this was something I meant to ask as well. Often the coastlines
> cross the rivers at completely arbitrary points. Thinking about it too
> much brings up the famous coastline paradox. Mapping it right back to
> the tidal limit does seem like the only way that isn't arbitrary. The
> Dart cuts the coastline off right at the mouth, which doesn't seem right
> at all to me. It would be good to be consistent.

I couldn't agree more! My vote is to go back to the tidal limit, for
exactly that reason. 

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

Re: [Talk-GB] UK coastline data

[Colin Smale]

Good point. Do you know of one? Let's have a look at how the OS deal
with it.

On 2019-07-11 22:52, Edward Catmur wrote:

> On Thu, Jul 11, 2019 at 9:19 PM Colin Smale  wrote: 
> 
>> * Where the coastline is essentially vertical (harbour walls, steep cliffs) 
>> MHWS and MLWS can coincide in OS data (sharing nodes but not ways), but of 
>> course low water can never be landward of high water.
> 
> Is this necessarily the case? Couldn't an overhang result in a low water 
> landward of high water? Consider e.g. a sea cave that is flooded at high tide.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] Website: Route auf OSM anzeigen

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 21:22, Markus  wrote:
> 
> Hier das erfolgreiche Ergebnis:
> https://schnaittach.feuerwehren.bayern/150-jahre-feuerwehr-schnaittach/


über Krankenhausweg oder Brauhausgasse könnte man die Sperren umgehen ;-)

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

Re: [Talk-GB] UK coastline data

[Edward Catmur via Talk-GB]

On Thu, Jul 11, 2019 at 9:19 PM Colin Smale  wrote:

> * Where the coastline is essentially vertical (harbour walls, steep
> cliffs) MHWS and MLWS can coincide in OS data (sharing nodes but not ways),
> but of course low water can never be landward of high water.
>
Is this necessarily the case? Couldn't an overhang result in a low water
landward of high water? Consider e.g. a sea cave that is flooded at high
tide.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 20:23, Kathleen Lu  wrote:
> 
> "Substantial investment" may not be a black and white standard, but it is a 
> meaningful one. I hypothesize that Tesco would have difficulty proving "a 
> substantial investment in either the obtaining, verification or presentation 
> of the contents." (Note that investment in creating/setting the hours does 
> not count.)


It may have come along as sarcasm the way I have written it, but the idea is 
actually appealing: significant investment wrt the database could eventually be 
dismissed for those databases, which are more or less the result of some 
related operation/work, a byproduct, rather than being set up to gather and 
analyze data without being required in the operation. The investment would be 
the operation, while the db as a byproduct would be almost “free”. The 
OpenStreetMap database would still be protected under perspective, but a lot of 
databases would not be protected automatically any more. 

The maps the GIS department releases are definitely requiring a significant 
investment, but the lists of streets a municipality releases would probably not 
be covered by the sui generis rule because there is not much specific 
investment behind such a compilation, it is a byproduct of their operation as a 
public administration. Or the post code lists of the postal service: the effort 
is not specifically put into the db, they only have to print what they already 
know from planning and organizing the postal service.

Is there already case law with examples where a claimed significant investment 
has been rejected? I would suspect that almost any database could be seen as 
having required a lot of investment for the creation and updates, or not, 
according to how you put it. 

From a practical point of view I agree I would not be worried about copying 
opening hours (or addresses, or phone numbers) from a retail company’s website, 
e.g. Tesco. It’s more likely they would pay you for this than sue you.

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

Re: [Talk-GB] UK coastline data

[Borbus]

On Thu, Jul 11, 2019 at 9:19 PM Colin Smale  wrote:
> I would recommend you don't refer to "the two coastlines" as this will
> just lead to confusion. The one true coastline is the high water line,
> taken to be MHWS (in England and Wales). The low water mark is also
> useful because that is where the jurisdiction of local authorities
> normally ends.

Oh yeah, the reason I wrote about the "other coastline" was because I
think it sometimes does cause confusion. In the area I was looking the
mapped coastline was sometimes the MHW, sometimes the MLW, and sometimes
it was mapped at the sea wall which in that case would be an
exceptionally high tide or storm surge. But yes, the coastline should
only be the MHW.

> * Coastal admin boundaries (the "Extent of the Realm") are usually MLWS,
>   but there are such things as "seaward extensions" which extend the
>   "realm" further into the water. Check out for example Brighton Marina,
>   Torbay, City of Bristol.

I have noticed the boundaries often correspond with MLW. I have tried to
leave the boundaries alone even when they overlap with the MLW because I
thought combining them might be confusing.

> * Where the "coastline" crosses the mouth of a river or estuary, there
>   has been lots of discussion about this in the past, as usual without a
>   clear definitive verdict. The OS data will take you upstream to the
>   tidal limit of rivers, which sometimes gives results which some people
>   find undesirable. Example: River Dart in Devon.

Yes, this was something I meant to ask as well. Often the coastlines
cross the rivers at completely arbitrary points. Thinking about it too
much brings up the famous coastline paradox. Mapping it right back to
the tidal limit does seem like the only way that isn't arbitrary. The
Dart cuts the coastline off right at the mouth, which doesn't seem right
at all to me. It would be good to be consistent.

> * The OS MHWS data will also place tidal inlets outside the coastline;
>   there is a proposal/vote underway which seems to confirm this, but
>   existing data might not:
>
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel

Yes, it does on the data I've been looking at. But this seems correct to
me for the same reason as the tidal extent of rivers.

> * My personal opinion is that the OS data is likely to be professionally
>   curated, and is probably the most accurate source we are ever going to
>   get. In many places you might conclude that it is wrong, when
>   comparing it to aerial imagery. However we will never know the tidal
>   conditions at the time of the imagery. The coastline, and the
>   low-water mark more so, is subject to change over the course of time,
>   and OS doesn't resurvey coastal boundaries very often (although they
>   seem to do it every few years). I would recommend adding the date of
>   the OS data to the OSM coastline, to aid future updates.

Yes, indeed. I regret not adding the version to the data I imported. I
suppose it could be determined from the date it was added to OSM. It
should be quite easy to keep it up to date, though. The "replace
geometry" plugin in JOSM is very useful for this.

Happy mapping,

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

Re: [Talk-at] minderwertige Importe

[Michael Reichert]

Hallo,

das ist noch keine Zusage, dass ich den Revert ("mechanischer Edit"
träfe es besser) mache, da ich nicht weiß, ob ich die Zeit dafür haben
werde. Die Kriterien können wir trotzdem klären.

Am 09.07.19 um 14:21 schrieb vari...@mailbox.org:
> Mein Vorschlag dazu ist:
> * Alles was noch v1 ist

Das Kriterium ist auf den ersten Blick machbar. Ich habe mir die
Änderungssätze bislang noch nicht angeschaut, daher die etwas dumme
Rückfrage meinerseits: Was tun, wenn ein v1-Node Mitglied eines
hochgeladenen Ways ist, der geändert worden ist (also jetzt v > 1), oder
später für einen Way verwendet worden ist?

Man kann die von ihm gesetzten Tags zu entfernen, wenn der
Node noch von einem Way oder einer Relation referenziert wird und diese
nicht auch gelöscht werden soll.

> * Changesets mit dem Beginn "Fehlende oder neue Adressen*"

Ab wann (Zeitpunkt) ist dieses Kriterium anzuwenden?

Viele Grüße

Michael

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





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

Re: [OSM-talk-fr] Indiquer un croisement

[Florian LAINEZ]

Merci Marc, je prend en compte tes remarques
@Fred OK j'imagine qu'il y a une bonne raison à cela.

Du coup j'ai changé pour place=square sur un polygone  et j'ai remplacé sur les adresses addr:street par addr:place

Le jeu. 11 juil. 2019 à 22:18,  a écrit :

> Pour un hameau avec des numéros mais pas de noms de rue, addr:place marche
> avec Nominatim et avec Osmose.
>
> Jean-Yvon
>
>
> > Gesendet: Donnerstag, 11. Juli 2019 um 22:14 Uhr
> > Von: "marc marc - marc_marc_...@hotmail.com"
> 
> > An: "talk-fr@openstreetmap.org" 
> > Betreff: Re: [OSM-talk-fr] Indiquer un croisement
> >
> > il ne faut pas tager/déformer la réalité pour osmose, de la même
> > manière qu'on ne tag/déforme pas pour le rendu.
> > une place n'est pas un carrefour, c'est bien plus que cela.
> > donc junction=yes est à mes yeux erroné.
> >
> > pour ajouter le nom de la place dans osm,
> > nommer la(es) rue(s) qui traverse(nt) la place avec le nom de la place
> > et/ou faire un objet place=square correspondent bien mieux à la réalité.
> >
> > pour les adresse, je suis mitigé pour addr:place car cela me semble pas
> > correspondre à la réalité, cela décrit le cas où un lieu n'a pas de nom
> > de rue comme par exemple un hameau.
> > dire qu'une ville utilise des noms de rue mais n'en a pas
> > pour une place, c'est un peu le slalom.
> > là aussi nommer la(es) rue(s) qui traverse(nt) la place avec le nom
> > de la place et garder des addr:street me semble mieux correspondre
> > à la réalité et en plus osmose le supporte :)
> >
> > Le 11.07.19 à 21:57, Florian LAINEZ a écrit :
> > > Merci Fred pour l'info.
> > > Je suis à deux doigts de changer d'avis et de créer un polygone qui
> > > englobe la place avec place=square
> > > C'est ce que tu me conseilles ou est-ce que tu penses qu'une évolution
> > > d'OSMOSE serait bienvenue ? J'applique ma politique "0 erreurs OSMOSE
> > > créées" ;)
> > >
> > > Le jeu. 11 juil. 2019 à 21:30, Frédéric Rodrigo <
> fred.rodr...@gmail.com
> > > > a écrit :
> > >
> > > Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :
> > >  > Ok j'ai mis
> > >  > junction=yes et name=Place Jean-Jaurès
> > >  > https://www.openstreetmap.org/node/6459511083
> > >  >
> > >  > à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut
> > > être
> > >  > avez-vous la réponse d'ailleurs).
> > >  > merci
> > >  >
> > >
> > > Avec le place=square tu avais encore une chance, en changeant le
> > > addr:street en addr:place.
> > >
> > > Mais avec junction=yes, pour faire le lien avec un addr:street,
> aucune
> > > chance.
> > >
> > >
> > >  > Le mer. 10 juil. 2019 à 20:50, <
> osm.sanspourr...@spamgourmet.com
> > > 
> > >  >  > > >> a écrit :
> > >  >
> > >  > Je suis d'accord : si on veut nommer une place place=square
> c'est
> > >  > fait pour ça.
> > >  >
> > >  > Éventuellement dans une relation si on veut à la fois le
> contour
> > >  > et les les tronçons de route les traversant.
> > >  >
> > >  > Maintenant s'il n'y a pas de trace sur le terrain, le
> > > polygone est
> > >  > sans doute suffisant.
> > >  >
> > >  > Une place sans nom affiché ? Il y a des cas étranges. Bah,
> on a
> > >  > bien des noms officiels et des noms pratiques. Si vous
> > > cherches la
> > >  > place de Gaulle à Brest mieux vaut avoir un plan que
> demander
> > > à un
> > >  > Brestois qui par contre vous indiquera la place du Château
> sans
> > >  > problème.
> > >  >
> > >  > Et une place c'est bien quelque chose de standard en Europe.
> > >  >
> > >
> > >
> > >
> > > --
> > >
> > > *Florian Lainez*
> > >
> > > @overflorian 
> > >
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-fr
> > >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [Talk-GB] UK coastline data

[Colin Smale]

Hi, 

Great! 

Don't worry about having "too many nodes" - the OS data is already
generalised a bit (I think they target 1:1) so it could be a lot
"worse". I spend a lot of time curating the admin boundaries;
occasionally I will update a bit of coastline from OS data when I am "in
the area". 

I would recommend you don't refer to "the two coastlines" as this will
just lead to confusion. The one true coastline is the high water line,
taken to be MHWS (in England and Wales). The low water mark is also
useful because that is where the jurisdiction of local authorities
normally ends. 

Danger lurks in a few areas: 

* Coastal admin boundaries (the "Extent of the Realm") are usually MLWS,
but there are such things as "seaward extensions" which extend the
"realm" further into the water. Check out for example Brighton Marina,
Torbay, City of Bristol. 

* Where the coastline is essentially vertical (harbour walls, steep
cliffs) MHWS and MLWS can coincide in OS data (sharing nodes but not
ways), but of course low water can never be landward of high water.
Structures like piers that are built out above the water can fall
outside of the low water line, and therefore also outside the admin
boundary. It is what it is. 

* Where the "coastline" crosses the mouth of a river or estuary, there
has been lots of discussion about this in the past, as usual without a
clear definitive verdict. The OS data will take you upstream to the
tidal limit of rivers, which sometimes gives results which some people
find undesirable. Example: River Dart in Devon. 

* The OS MHWS data will also place tidal inlets outside the coastline;
there is a proposal/vote underway which seems to confirm this, but
existing data might not:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel


* My personal opinion is that the OS data is likely to be professionally
curated, and is probably the most accurate source we are ever going to
get. In many places you might conclude that it is wrong, when comparing
it to aerial imagery. However we will never know the tidal conditions at
the time of the imagery. The coastline, and the low-water mark more so,
is subject to change over the course of time, and OS doesn't resurvey
coastal boundaries very often (although they seem to do it every few
years). I would recommend adding the date of the OS data to the OSM
coastline, to aid future updates.

Cheers, 

Colin 

On 2019-07-11 21:38, Borbus wrote:

> Hi, 
> 
> I've recently done an import of coastline data from OS VectorMap into OSM 
> around The Wash. I did this because I'm interested in coastal regions and the 
> coastline was a complete mess in that area. I'm sure it's similar in other 
> parts of GB as well. 
> 
> The mess often happens because mappers don't necessarily know what a 
> "coastline" is (I didn't before I researched it). For land-based maps the 
> coastline that is shown is generally shown is mean high water level. The 
> other "coastline" that is also shown on land-based maps is the mean lower 
> water level. The bit between these lines is the intertidal zone. This is 
> admittedly a bit less interesting, but it's certainly useful when there are 
> causeways and other features in the intertidal zone. The actual high and low 
> tides can be higher or lower than the means. The tide varies throughout the 
> month and the highest highs and lowest lows are called spring tides. Nautical 
> charts will show the lowest low, not mean low. 
> 
> This seems like quite difficult data to obtain so using OS seems to be the 
> obvious choice here. I'm pleased with how the import went in The Wash. It 
> integrated well with the existing OSM data around the coastline. It's 
> certainly a lot easier to integrate than groundwater but it does require a 
> lot of manual processing. 
> 
> But before I start importing other areas (I'm looking at the Blackwater 
> estuary next), I want to discuss it with others because I'm concerned that 
> the way I've done it could negatively impact other mappers. 
> 
> The data as it comes is essentially the two coastlines as described above: 
> MHW and MLW. The MHW can just replace the existing coastline in OSM. It adds 
> many, many more nodes to the coastlines, and possibly more ways too. The MLW 
> along with MHW then can form multipolygons containing the intertidal zone, 
> which is mapped as a wetland=tidalflat. 
> 
> Using the coastline to make multipolygons means the coastline is broken up 
> into many, many small ways. One concern is that the GB island multipolygon 
> will become very hard to maintain. On my computer JOSM is very slow to 
> operate when I load this multipolygon. 
> 
> So before I continue I'd like to give people the chance to tell me to stop 
> and, if necessary, suggest a better way to do this import. Or maybe people 
> wouldn't like to see this import done at all. Personally I think there is 
> value in integrating the data but some may disagree. 
> 
> Happy mapping, 
> 
> 

Re: [OSM-talk-fr] Indiquer un croisement

[osm . sanspourriel]

Pour un hameau avec des numéros mais pas de noms de rue, addr:place marche avec 
Nominatim et avec Osmose.

Jean-Yvon


> Gesendet: Donnerstag, 11. Juli 2019 um 22:14 Uhr
> Von: "marc marc - marc_marc_...@hotmail.com" 
> 
> An: "talk-fr@openstreetmap.org" 
> Betreff: Re: [OSM-talk-fr] Indiquer un croisement
>
> il ne faut pas tager/déformer la réalité pour osmose, de la même
> manière qu'on ne tag/déforme pas pour le rendu.
> une place n'est pas un carrefour, c'est bien plus que cela.
> donc junction=yes est à mes yeux erroné.
> 
> pour ajouter le nom de la place dans osm,
> nommer la(es) rue(s) qui traverse(nt) la place avec le nom de la place
> et/ou faire un objet place=square correspondent bien mieux à la réalité.
> 
> pour les adresse, je suis mitigé pour addr:place car cela me semble pas 
> correspondre à la réalité, cela décrit le cas où un lieu n'a pas de nom 
> de rue comme par exemple un hameau.
> dire qu'une ville utilise des noms de rue mais n'en a pas
> pour une place, c'est un peu le slalom.
> là aussi nommer la(es) rue(s) qui traverse(nt) la place avec le nom
> de la place et garder des addr:street me semble mieux correspondre
> à la réalité et en plus osmose le supporte :)
> 
> Le 11.07.19 à 21:57, Florian LAINEZ a écrit :
> > Merci Fred pour l'info.
> > Je suis à deux doigts de changer d'avis et de créer un polygone qui 
> > englobe la place avec place=square
> > C'est ce que tu me conseilles ou est-ce que tu penses qu'une évolution 
> > d'OSMOSE serait bienvenue ? J'applique ma politique "0 erreurs OSMOSE 
> > créées" ;)
> > 
> > Le jeu. 11 juil. 2019 à 21:30, Frédéric Rodrigo  > > a écrit :
> > 
> > Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :
> >  > Ok j'ai mis
> >  > junction=yes et name=Place Jean-Jaurès
> >  > https://www.openstreetmap.org/node/6459511083
> >  >
> >  > à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut
> > être
> >  > avez-vous la réponse d'ailleurs).
> >  > merci
> >  >
> > 
> > Avec le place=square tu avais encore une chance, en changeant le
> > addr:street en addr:place.
> > 
> > Mais avec junction=yes, pour faire le lien avec un addr:street, aucune
> > chance.
> > 
> > 
> >  > Le mer. 10 juil. 2019 à 20:50,  > 
> >  >  > >> a écrit :
> >  >
> >  >     Je suis d'accord : si on veut nommer une place place=square c'est
> >  >     fait pour ça.
> >  >
> >  >     Éventuellement dans une relation si on veut à la fois le contour
> >  >     et les les tronçons de route les traversant.
> >  >
> >  >     Maintenant s'il n'y a pas de trace sur le terrain, le
> > polygone est
> >  >     sans doute suffisant.
> >  >
> >  >     Une place sans nom affiché ? Il y a des cas étranges. Bah, on a
> >  >     bien des noms officiels et des noms pratiques. Si vous
> > cherches la
> >  >     place de Gaulle à Brest mieux vaut avoir un plan que demander
> > à un
> >  >     Brestois qui par contre vous indiquera la place du Château sans
> >  >     problème.
> >  >
> >  >     Et une place c'est bien quelque chose de standard en Europe.
> >  >
> > 
> > 
> > 
> > -- 
> > 
> > *Florian Lainez*
> > 
> > @overflorian 
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> > 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Indiquer un croisement

[marc marc]

il ne faut pas tager/déformer la réalité pour osmose, de la même
manière qu'on ne tag/déforme pas pour le rendu.
une place n'est pas un carrefour, c'est bien plus que cela.
donc junction=yes est à mes yeux erroné.

pour ajouter le nom de la place dans osm,
nommer la(es) rue(s) qui traverse(nt) la place avec le nom de la place
et/ou faire un objet place=square correspondent bien mieux à la réalité.

pour les adresse, je suis mitigé pour addr:place car cela me semble pas 
correspondre à la réalité, cela décrit le cas où un lieu n'a pas de nom 
de rue comme par exemple un hameau.
dire qu'une ville utilise des noms de rue mais n'en a pas
pour une place, c'est un peu le slalom.
là aussi nommer la(es) rue(s) qui traverse(nt) la place avec le nom
de la place et garder des addr:street me semble mieux correspondre
à la réalité et en plus osmose le supporte :)

Le 11.07.19 à 21:57, Florian LAINEZ a écrit :
> Merci Fred pour l'info.
> Je suis à deux doigts de changer d'avis et de créer un polygone qui 
> englobe la place avec place=square
> C'est ce que tu me conseilles ou est-ce que tu penses qu'une évolution 
> d'OSMOSE serait bienvenue ? J'applique ma politique "0 erreurs OSMOSE 
> créées" ;)
> 
> Le jeu. 11 juil. 2019 à 21:30, Frédéric Rodrigo  > a écrit :
> 
> Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :
>  > Ok j'ai mis
>  > junction=yes et name=Place Jean-Jaurès
>  > https://www.openstreetmap.org/node/6459511083
>  >
>  > à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut
> être
>  > avez-vous la réponse d'ailleurs).
>  > merci
>  >
> 
> Avec le place=square tu avais encore une chance, en changeant le
> addr:street en addr:place.
> 
> Mais avec junction=yes, pour faire le lien avec un addr:street, aucune
> chance.
> 
> 
>  > Le mer. 10 juil. 2019 à 20:50,  
>  >  >> a écrit :
>  >
>  >     Je suis d'accord : si on veut nommer une place place=square c'est
>  >     fait pour ça.
>  >
>  >     Éventuellement dans une relation si on veut à la fois le contour
>  >     et les les tronçons de route les traversant.
>  >
>  >     Maintenant s'il n'y a pas de trace sur le terrain, le
> polygone est
>  >     sans doute suffisant.
>  >
>  >     Une place sans nom affiché ? Il y a des cas étranges. Bah, on a
>  >     bien des noms officiels et des noms pratiques. Si vous
> cherches la
>  >     place de Gaulle à Brest mieux vaut avoir un plan que demander
> à un
>  >     Brestois qui par contre vous indiquera la place du Château sans
>  >     problème.
>  >
>  >     Et une place c'est bien quelque chose de standard en Europe.
>  >
> 
> 
> 
> -- 
> 
> *Florian Lainez*
> 
> @overflorian 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [Talk-de] Website: Route auf OSM anzeigen

[Ludwig Baumgart]

das ist ja super! es kommt mir/uns hier in BadenWürttemberg für das 
Dorfkartenprojekt wie gerufen, zumal wir uns letzte Woche als 
"Bodensee-Stammtisch" das erste Mal trafen und ein Feuerwehrprojekt hier 
im Raum Schaffhausen-Singen angehen wollen (mit OSM und QGIS) ...

herzlichen Dank für diese Anregung,
Ludwig

Am 11.07.19 um 21:22 schrieb Markus:

Wow - beeindrucken Eure schnelle und fundierte Hilfe :-)

Herzlichen Dank an alle!

Hier das erfolgreiche Ergebnis:
https://schnaittach.feuerwehren.bayern/150-jahre-feuerwehr-schnaittach/

Mit herzlichem Gruss,
Markus



Am 11.07.2019 um 08:16 schrieb Elstermann, Mike:

Sieh mal hier:
https://geoobserver.wordpress.com/2019/06/17/umap-diy-karte-mit-osm-daten/

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




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

[OSM-talk-fr] Traductions de page wiki OSM en français

[severin.menard via Talk-fr]

Bonsoir à tous,

J'ai traduit en français la semaine dernière la page wiki intitulée Any tag you 
like qui explique les fondamentaux de la création d'attributs dans OSM :

https://wiki.openstreetmap.org/wiki/FR:Cr%C3%A9er_un_attribut_qui_manque

J'ai remarqué que pas mal de pages wiki en lien dans cette page restaient en 
mal de traduction en français, si certains sont motivés :

https://wiki.openstreetmap.org/wiki/Names#Localization
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
https://wiki.openstreetmap.org/wiki/FR:Espaces_de_noms

Même chose pour certaines clés, par exemple :

https://wiki.openstreetmap.org/wiki/Key:drinking_water
https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:

Séverin___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Indiquer un croisement

[Frédéric Rodrigo]

Pas de addr:junction en vue
https://taginfo.openstreetmap.org/search?q=addr%3A


Le 11/07/2019 à 21:57, Florian LAINEZ a écrit :

Merci Fred pour l'info.
Je suis à deux doigts de changer d'avis et de créer un polygone qui 
englobe la place avec place=square
C'est ce que tu me conseilles ou est-ce que tu penses qu'une évolution 
d'OSMOSE serait bienvenue ? J'applique ma politique "0 erreurs OSMOSE 
créées" ;)


Le jeu. 11 juil. 2019 à 21:30, Frédéric Rodrigo 
mailto:fred.rodr...@gmail.com>> a écrit :


Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :
> Ok j'ai mis
> junction=yes et name=Place Jean-Jaurès
> https://www.openstreetmap.org/node/6459511083
>
> à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut
être
> avez-vous la réponse d'ailleurs).
> merci
>

Avec le place=square tu avais encore une chance, en changeant le
addr:street en addr:place.

Mais avec junction=yes, pour faire le lien avec un addr:street,
aucune
chance.


> Le mer. 10 juil. 2019 à 20:50, mailto:osm.sanspourr...@spamgourmet.com>
> >> a écrit :
>
>     Je suis d'accord : si on veut nommer une place place=square
c'est
>     fait pour ça.
>
>     Éventuellement dans une relation si on veut à la fois le contour
>     et les les tronçons de route les traversant.
>
>     Maintenant s'il n'y a pas de trace sur le terrain, le
polygone est
>     sans doute suffisant.
>
>     Une place sans nom affiché ? Il y a des cas étranges. Bah, on a
>     bien des noms officiels et des noms pratiques. Si vous
cherches la
>     place de Gaulle à Brest mieux vaut avoir un plan que
demander à un
>     Brestois qui par contre vous indiquera la place du Château sans
>     problème.
>
>     Et une place c'est bien quelque chose de standard en Europe.
>



--

*Florian Lainez*

@overflorian 




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

Re: [Talk-GB] UK coastline data

[Ed Loach]

You'll probably get comments about import guidelines but I did similar for 
Tendring about 9 years ago before there were any. I think your use of the word 
import in this scenario may be misleading as you're not bulk importing the 
whole coastline but selectively improving sections of coastline by manually 
improving existing data by using a small subset of available opendata.

If you're using JOSM you can remove excess nodes (which I didn't know at the 
time and have tried to clear up a bit since).

Coastlines take some care when editing so you don't flood the country; from 
your post and the lack of any recent issues you've proved you can handle this.

Coastlines change over time - locally a coastal protection scheme added a few 
fish tailed groynes to MHW so I replaced that short section when the data 
became available (too recent to trace from imagery).

OSM is a process of continual improvement. I would say if you are doing small 
areas manually with care rather than bulk importing the whole coastline then 
carry on doing areas if you're willing to maintain them too.

Best wishes,

Ed

From: Borbus 
Sent: Thursday, July 11, 2019 8:38:39 PM
To: talk-gb@openstreetmap.org
Subject: [Talk-GB] UK coastline data

Hi,

I've recently done an import of coastline data from OS VectorMap into OSM 
around The Wash. I did this because I'm interested in coastal regions and the 
coastline was a complete mess in that area. I'm sure it's similar in other 
parts of GB as well.

The mess often happens because mappers don't necessarily know what a 
"coastline" is (I didn't before I researched it). For land-based maps the 
coastline that is shown is generally shown is mean high water level. The other 
"coastline" that is also shown on land-based maps is the mean lower water 
level. The bit between these lines is the intertidal zone. This is admittedly a 
bit less interesting, but it's certainly useful when there are causeways and 
other features in the intertidal zone. The actual high and low tides can be 
higher or lower than the means. The tide varies throughout the month and the 
highest highs and lowest lows are called spring tides. Nautical charts will 
show the lowest low, not mean low.

This seems like quite difficult data to obtain so using OS seems to be the 
obvious choice here. I'm pleased with how the import went in The Wash. It 
integrated well with the existing OSM data around the coastline. It's certainly 
a lot easier to integrate than groundwater but it does require a lot of manual 
processing.

But before I start importing other areas (I'm looking at the Blackwater estuary 
next), I want to discuss it with others because I'm concerned that the way I've 
done it could negatively impact other mappers.

The data as it comes is essentially the two coastlines as described above: MHW 
and MLW. The MHW can just replace the existing coastline in OSM. It adds many, 
many more nodes to the coastlines, and possibly more ways too. The MLW along 
with MHW then can form multipolygons containing the intertidal zone, which is 
mapped as a wetland=tidalflat.

Using the coastline to make multipolygons means the coastline is broken up into 
many, many small ways. One concern is that the GB island multipolygon will 
become very hard to maintain. On my computer JOSM is very slow to operate when 
I load this multipolygon.

So before I continue I'd like to give people the chance to tell me to stop and, 
if necessary, suggest a better way to do this import. Or maybe people wouldn't 
like to see this import done at all. Personally I think there is value in 
integrating the data but some may disagree.

Happy mapping,

Borbus.

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

Re: [OSM-talk-fr] Indiquer un croisement

[Florian LAINEZ]

Merci Fred pour l'info.
Je suis à deux doigts de changer d'avis et de créer un polygone qui englobe
la place avec place=square
C'est ce que tu me conseilles ou est-ce que tu penses qu'une évolution
d'OSMOSE serait bienvenue ? J'applique ma politique "0 erreurs OSMOSE
créées" ;)

Le jeu. 11 juil. 2019 à 21:30, Frédéric Rodrigo  a
écrit :

> Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :
> > Ok j'ai mis
> > junction=yes et name=Place Jean-Jaurès
> > https://www.openstreetmap.org/node/6459511083
> >
> > à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut être
> > avez-vous la réponse d'ailleurs).
> > merci
> >
>
> Avec le place=square tu avais encore une chance, en changeant le
> addr:street en addr:place.
>
> Mais avec junction=yes, pour faire le lien avec un addr:street, aucune
> chance.
>
>
> > Le mer. 10 juil. 2019 à 20:50,  > > a écrit :
> >
> > Je suis d'accord : si on veut nommer une place place=square c'est
> > fait pour ça.
> >
> > Éventuellement dans une relation si on veut à la fois le contour
> > et les les tronçons de route les traversant.
> >
> > Maintenant s'il n'y a pas de trace sur le terrain, le polygone est
> > sans doute suffisant.
> >
> > Une place sans nom affiché ? Il y a des cas étranges. Bah, on a
> > bien des noms officiels et des noms pratiques. Si vous cherches la
> > place de Gaulle à Brest mieux vaut avoir un plan que demander à un
> > Brestois qui par contre vous indiquera la place du Château sans
> > problème.
> >
> > Et une place c'est bien quelque chose de standard en Europe.
> >
>
>

-- 

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

[Talk-GB] UK coastline data

[Borbus]

Hi,

I've recently done an import of coastline data from OS VectorMap into OSM
around The Wash. I did this because I'm interested in coastal regions and
the coastline was a complete mess in that area. I'm sure it's similar in
other parts of GB as well.

The mess often happens because mappers don't necessarily know what a
"coastline" is (I didn't before I researched it). For land-based maps the
coastline that is shown is generally shown is mean high water level. The
other "coastline" that is also shown on land-based maps is the mean lower
water level. The bit between these lines is the intertidal zone. This is
admittedly a bit less interesting, but it's certainly useful when there are
causeways and other features in the intertidal zone. The actual high and
low tides can be higher or lower than the means. The tide varies throughout
the month and the highest highs and lowest lows are called spring tides.
Nautical charts will show the lowest low, not mean low.

This seems like quite difficult data to obtain so using OS seems to be the
obvious choice here. I'm pleased with how the import went in The Wash. It
integrated well with the existing OSM data around the coastline. It's
certainly a lot easier to integrate than groundwater but it does require a
lot of manual processing.

But before I start importing other areas (I'm looking at the Blackwater
estuary next), I want to discuss it with others because I'm concerned that
the way I've done it could negatively impact other mappers.

The data as it comes is essentially the two coastlines as described above:
MHW and MLW. The MHW can just replace the existing coastline in OSM. It
adds many, many more nodes to the coastlines, and possibly more ways too.
The MLW along with MHW then can form multipolygons containing the
intertidal zone, which is mapped as a wetland=tidalflat.

Using the coastline to make multipolygons means the coastline is broken up
into many, many small ways. One concern is that the GB island multipolygon
will become very hard to maintain. On my computer JOSM is very slow to
operate when I load this multipolygon.

So before I continue I'd like to give people the chance to tell me to stop
and, if necessary, suggest a better way to do this import. Or maybe people
wouldn't like to see this import done at all. Personally I think there is
value in integrating the data but some may disagree.

Happy mapping,

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

Re: [OSM-talk-fr] Indiquer un croisement

[Frédéric Rodrigo]

Le 11/07/2019 à 19:16, Florian LAINEZ via Talk-fr a écrit :

Ok j'ai mis
junction=yes et name=Place Jean-Jaurès
https://www.openstreetmap.org/node/6459511083

à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut être 
avez-vous la réponse d'ailleurs).

merci



Avec le place=square tu avais encore une chance, en changeant le 
addr:street en addr:place.


Mais avec junction=yes, pour faire le lien avec un addr:street, aucune 
chance.



Le mer. 10 juil. 2019 à 20:50, > a écrit :


Je suis d'accord : si on veut nommer une place place=square c'est
fait pour ça.

Éventuellement dans une relation si on veut à la fois le contour
et les les tronçons de route les traversant.

Maintenant s'il n'y a pas de trace sur le terrain, le polygone est
sans doute suffisant.

Une place sans nom affiché ? Il y a des cas étranges. Bah, on a
bien des noms officiels et des noms pratiques. Si vous cherches la
place de Gaulle à Brest mieux vaut avoir un plan que demander à un
Brestois qui par contre vous indiquera la place du Château sans
problème.

Et une place c'est bien quelque chose de standard en Europe.




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

Re: [Talk-de] Website: Route auf OSM anzeigen

[Markus]

Wow - beeindrucken Eure schnelle und fundierte Hilfe :-)

Herzlichen Dank an alle!

Hier das erfolgreiche Ergebnis:
https://schnaittach.feuerwehren.bayern/150-jahre-feuerwehr-schnaittach/

Mit herzlichem Gruss,
Markus



Am 11.07.2019 um 08:16 schrieb Elstermann, Mike:
> Sieh mal hier:
> https://geoobserver.wordpress.com/2019/06/17/umap-diy-karte-mit-osm-daten/

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

Re: [OSM-Talk-ZA] Mapping traditional councils as boundary=aboriginal_lands

[Adrian Frith]

There are 800 in the shapefile that I have from DRLDR. I guess the
next step is to get permission from them and then talk to the Data
Working Group.

On Sat, 6 Jul 2019 at 10:47, Reuben Honigwachs via Talk-ZA
 wrote:
>
> Since nobody has chimed in, yet, let me say this is a wonderful idea and I'll 
> gladly support the effort.
>
> Do you have a rough idea of how many there are?
>
> Best, Reuben
>
> On Mon, 1 Jul 2019 at 15:20, Adrian Frith  wrote:
>>
>> Hi talk-za,
>>
>> Do you think it would be appropriate for us to map the traditional
>> councils (formerly "tribal authorities") with the tag
>> boundary=aboriginal_lands[1]? I have mapped one as an example
>> (Batlhaping ba ga Mothibi) which you can see on the map at [2].
>>
>> If we were to go ahead I suppose we might have to get formal
>> permission from the Department of Rural Development and Land Reform
>> which seems to be the custodian of the boundary data (of which I have
>> a copy).
>>
>> Your thoughts?
>> Adrian
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands
>> [2] https://www.openstreetmap.org/#map=10/-27.8342/24.5359

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

Re: [Talk-at] minderwertige Importe

[andreas wecer via Talk-at]

Am Do., 11. Juli 2019 um 16:02 Uhr schrieb Andreas :

> Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
> filtern und vola sind die Zähladressen weg.
>

Quelladresse und Bestimmungsart hatte ich mir schon einmal kurz angesehen,
aber sie sind nicht dazu geeignet seine Problemfälle zu identifizieren. Andere
Tests  sind da zwar
tlw. erfolgreicher, allerdings frage ich mich auch, ob es nicht wie schon
vorgeschlagen sinnvoller wäre alle Nodes mit v1 ab dem angesprochenen
Salzburg-Changeset zu löschen. Er halst nur allen anderen Ärger und Aufwand
auf, macht keinerlei Anstalten irgendetwas an den Problemen zu beseitigen
(ehrlich gesagt weiß ich allerdings auch nicht, ob wir das bei seiner
Vorgangsweise wirklich wollen - zumindest wurden im Moment noch wenig
existierende Daten geändert), feiert sich trotz aller Kritik und Probleme
weiterhin selbst für diesen Import und wenn sich lokale Mapper völlig
zurecht beschweren, weil in der zuvor vollständig erfassten Ortschaft
plötzlich alle Adressen verschwunden sind, können sie sich als Antwort auch
noch irgendwelche Vorwürfe bzgl. großer Lücken anhören
https://www.openstreetmap.org/changeset/71043800

Warum soll so ein Import nur in Zukunft nicht mehr vorkommen und dieser
hier toleriert werden, wo er innerhalb weniger Tage völlig unkontrolliert
hunderttausende Nodes importiert hat, ohne sich überhaupt irgendwelche
Gedanken zu machen, außer wie er die Limitierung beseitigen kann, dass die
Daten gesperrt und auf Straßenebene segmentiert sind? Und das obwohl ihm,
wie JM82 im Forum
 richtig
bemerkt hat, seit mind. 3-4 Jahren immer wieder erklärt wird, dass diese
Daten auch fehlerhaft sind und er sie nicht einfach in Gegenden, zu denen
er überhaupt keinen Bezug hat, völlig unreflektiert übernehmen soll.
Und jetzt sitzt ihm schon wieder ein Floh im Ohr, dass sein Vorgehen
eigentlich völlig ok war und nur eine minimale Änderung an den Daten
notwendig wäre.

LG
  Andreas
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[Kathleen Lu via legal-talk]

I understand the inclination to sarcasm, but your second statement is
simply not a logical one. A state's records of it's plans to build and
maintain roads aren't a map, and a typical map has many things on it other
than just roads. The plans by themselves may not be a protected database
under EU law, but governments discuss quite publicly the costs and efforts
of their GIS departments. "Substantial investment" may not be a black and
white standard, but it is a meaningful one. I hypothesize that Tesco would
have difficulty proving "a substantial investment in either the obtaining,
verification or presentation of the contents." (Note that investment in
creating/setting the hours does not count.)
Best,
Kathleen


On Wed, Jul 10, 2019 at 12:34 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 10. Jul 2019, at 18:35, Kathleen Lu via legal-talk <
> legal-talk@openstreetmap.org> wrote:
> >
> > I do not think that a retail store chain could successfully argue that
> it makes a "substantial investment" in maintaining a list of its own
> stores' hours. Since the store sets the hours, the effort of obtaining,
> verification, and/or presentation should be fairly trivial.
>
>
> Along the same reasoning you could say: “I do not think that a state makes
> a substantial investment in mapping the roads they maintain. Since the
> state plans, builds and maintains the roads it should be fairly trivial for
> them to make a map.”
>
> Cheers, Martin
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-at] minderwertige Importe

[Michael Reichert]

Hallo,

Am 11.07.19 um 15:15 schrieb vari...@mailbox.org:
> Er ist gerade im "Ich gehe auf Urlaub, ihr macht das jetzt mal fertig, bis 
> ich wieder da bin." Wo kämen wir denn hin, wenn er selbst zumindest eine 
> erste Version geliefert hätte. (Keine Angst Johann, brauchst du nicht und ich 
> hoffe, du wirst niemand im Namen von OSM anschreiben). + er ist gerade 
> gesperrt und kann sowieso nichts machen.

Er ist nur im Forum gesperrt, mappen kann er noch.
https://www.openstreetmap.org/user/addresshistory*org/blocks

> Aber Frederik Ramm hat eigentlich auch angeboten, dass das seitens der DWG 
> gemacht wird. Sollte ja einfach sein, Begründung ist ja immerhin 
> "Unabgeklärter Import." Und noch dazu schlecht gemacht. Aber wenn die DWG das 
> nicht machen will, dann muss eben die Community selbst ran, wie es aussieht.

Wenn die Diskussion läuft, dürfte es aus der DWG-Perspektive unklug
sein, Fakten zu schaffen. Reverts von Importen haben ja das Ziel,
geschaffene Fakten zurückzusetzen.

Ansonsten gilt auch da, dass das alles Freiwillige sind. Reverten kann
jeder, der sich dazu in der Lage sieht, das in verantwortlicher Art und
Weise zu tun. Es dürfen sich Leute gerne mit den Revert-Werkzeugen
beschäftigen. Es schadet nicht, wenn mehr Leute wissen, wie man
revertiert, weil das die Arbeit auf mehr Schultern verteilt. Es gibt ja
nicht nur addresshistory*org, sondern noch genügend andere Fälle. Und
meine To-Do-Liste enthält auch noch anderes als addresshistory*org.

Viele Grüße

Michael

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



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

Re: [OSM-talk-fr] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[Frédéric Rodrigo]

Le 11/07/2019 à 19:20, Christian Quest a écrit :

Content de voir que vous avez avancé sur cette GROSSE source de données !

J'ai trouvé beaucoup de coiffeurs sans salon de coiffure... les 
entreprises individuelles ont-elles bien été filtrées ?

Pareil pour les esthéticiennes... ça se pratique pas mal à domicile.


Non. Pour l'instant elles y sont, sauf pour les fast_food.

J'avais peur que ce soit un peu excessif de généraliser ce filtre.




Il y a assez peu de noms, d'enseignes indiqués.

Le SIRET n'est pas proposé/indiqué... ça serait bien pour accéder à la 
source SIRENE et vérifier le reste des infos.


Oui, je vais le remettre, au moins pour ça.



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

Re: [Talk-at] Wie weiter mit dem Troll?

[Rudolf Mayer]

Hallo,

auch mir nimmt der ständige Monolog und das "ich mach wonach mir ist" 
tun von Johann einfach zu viel Zeit. Nachdem es keine konstruktive 
Diskussion mit ihm geben kann, würde ich hier einen Schlußstrich ziehen.


Ich bin daher stark dafür, dass es hier ein deutliches Zeichen geben 
muss, würde darum die DWG bitten, dass sein Account in OSM wieder 
gesperrt wird, und in der Tat alle Edits von Ihm, die zumindest noch 
nicht weiterbearbeitet wurden, gelöscht werden.



Besonder bedenklich finde ich den Vorschlag, dass wenn er Duplikate 
kreiert, das ältere Objekt gelsöcht werden soll, damit zerstört man sehr 
viel historische Information, und stellt die Herkunft der echten 
Datenbasis falsch da.



Lg
Rudi


gppes_osm--- via Talk-at wrote on 11/07/2019 15:15:

Ich bin da aehnlicher Meinung wie Du.

Verstoesse gegen die Netiquette -> Ahndung.

Gleiches sehe ich aber bei wiederholtem kundtun der selben Meinung in der 
Hoffnung, dass man damit jemanden durch Quantitaet ueberzeugen koennte.

Im AT Forum wurden schon - aus meiner Sicht zu Recht - temporaere Sperren 
verhaengt. Gibt es so etwas fuer die Mailingliste auch?

Lg, Gppes


Gesendet: Donnerstag, 11. Juli 2019 um 10:42 Uhr
Von: "Norbert Wenzel" 
An: talk-at@openstreetmap.org
Betreff: Re: [Talk-at] Wie weiter mit dem Troll?

On 11.07.19 09:33, Florian Ledermann wrote:

ich wollte mal die Frage in den Raum stellen, wie die Mailingliste
gedenkt mit der Situation umzugehen, dass eine Person hier
kontinuierlich die Liste [...] missbraucht, [...]


Zur Info: ich bin ein Listenadmin. Ich mach das jetzt seit etwa 10
Jahren und hab erst ein einziges Mal aktiv moderiert (d.h. Mails von
bekannten Absendern nicht mehr automatisch durchgelassen). Und das war
wegen wiederholter, unsubstantiierter Anschuldigungen gegen Personen auf
der Liste.

Ich denke nicht, dass ich in meiner Funktion als Listenadmin hier,
abseits von direkten Netiquetteverstößen *auf der Liste*, eingreifen
sollte. Auch, weil es nichts daran ändern würde dass die Importe
durchgeführt werden und ein gesperrter User im Nachhinein sagen kann, er
habe versucht anzukündigen und zu diskutieren, aber er war ja
gesperrt/wurde ignoriert.


Ich weiß nicht wie die Foundation das normalerweise handhabt, aber ich
denke wenn jemand beständig gegen die Regeln der Community arbeitet und
auch keinerlei Einsicht in Diskussionen erkennen lässt, dann ist so
jemand nicht für ein Communityprojekt geeignet.

Aber das ist ein Problem von OSM als Ganzem bzw. der Foundation und
nicht nur der Mailingliste hier.


Für deine private Mailbox kann natürlich ein Filter, wie er von Stefan
vorgeschlagen wurde, zumindest dir persönlich Linderung verschaffen.


lg,
Norbert

PS: (Andere) Ansichten zur Rolle des Listenadmin können und sollen gerne
hier deponiert werden. Wenn es einen Konsens hier gibt, leg ich meine
Rolle gerne entsprechend aus.

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



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




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

Re: [OSM-talk-fr] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[Christian Quest]

Content de voir que vous avez avancé sur cette GROSSE source de données !

J'ai trouvé beaucoup de coiffeurs sans salon de coiffure... les entreprises
individuelles ont-elles bien été filtrées ?
Pareil pour les esthéticiennes... ça se pratique pas mal à domicile.

Il y a assez peu de noms, d'enseignes indiqués.

Le SIRET n'est pas proposé/indiqué... ça serait bien pour accéder à la
source SIRENE et vérifier le reste des infos.

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

Re: [OSM-talk-fr] Indiquer un croisement

[Florian LAINEZ via Talk-fr]

Ok j'ai mis
junction=yes et name=Place Jean-Jaurès
https://www.openstreetmap.org/node/6459511083

à voir si OSMOSE arrêtera de gueuler pour les adresses ... (peut être
avez-vous la réponse d'ailleurs).
merci

Le mer. 10 juil. 2019 à 20:50,  a écrit :

> Je suis d'accord : si on veut nommer une place place=square c'est fait
> pour ça.
>
> Éventuellement dans une relation si on veut à la fois le contour et les
> les tronçons de route les traversant.
>
> Maintenant s'il n'y a pas de trace sur le terrain, le polygone est sans
> doute suffisant.
>
> Une place sans nom affiché ? Il y a des cas étranges. Bah, on a bien des
> noms officiels et des noms pratiques. Si vous cherches la place de Gaulle à
> Brest mieux vaut avoir un plan que demander à un Brestois qui par contre
> vous indiquera la place du Château sans problème.
>
> Et une place c'est bien quelque chose de standard en Europe.
> Le 09/07/2019 à 17:46, althio - althio.fo...@gmail.com a écrit :
>
> Julien djakk:
>
> Salut ! Regarde le cas sud-coréen ou japonais !
>
> C'est ici 
> :https://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names
>
> Et... c'est le cas sud-coréen ou japonais !
> C'est (très très) minoritaire en France, d'avoir des noms spécifiques
> à de simples croisements/carrefours. Et où les noms des croisements
> sont plus importants que le nom des rues.
>
> Alors que une place, c'est significatif, en France et pays alentours.
>
>
> avec https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare
>
> C'est mon avis.
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [Talk-br] Road network improvements in Brazil

[Joao Porto de Albuquerque]

Hi Andrew, OSM community

Thanks for the message and for asking on suggestions for places to improve
road network. We are currently running a research project with flood-prone
communities and schools to map local risk perceptions based on the basemap
from OSM in the cities of São Paulo and Rio Branco. In Rio Branco (North
region) in particular we realised there is quite a lot to do to improve the
road network:

https://www.openstreetmap.org/relation/326253#map=14/-9.9773/-67.8386

We did some mapping there and taught school children to map with ID, but
the data will certainly needs review. If you guys would do some mapping
there we would certainly appreciate, as our project can focus on adding
local details to the map with the school children .

Best wishes
João
--
Professor João Porto de Albuquerque
Director | Institute of Global Sustainable Development | University of
Warwick, UK




On Thu, 11 Jul 2019 at 17:41, Andrew Wiseman por (Talk-br) <
talk-br@openstreetmap.org> wrote:

> Hi OSM Brazil,
>
> This is Andrew again from the Maps team at Apple, a few months ago I wrote
> that we were planning to start a project improving the road network in
> Brazil, things like adding missing roads, making sure roads connect
> properly, fixing incorrect alignments with GPS traces, ensuring road
> classifications are consistent, and other similar issues. Thank you for
> your feedback then, we incorporated it into our project.
>
> We did some analysis and plan to start in the North and Northeast regions
> of the country. I wanted to see if you had any suggestions for places
> that might have errors or have missing roads, or other issues in that area.
> There is more information about our project here:
> https://github.com/osmlab/appledata/issues/126
>
> Thank you,
>
> Andrew
>
> Apple, Inc.
>
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
> On Nov 9, 2018, at 11:37 AM, Andrew Wiseman 
> wrote:
>
> Hello OSM Brazil,
>
> My name is Andrew Wiseman, I work for Apple on the Maps team. My team is
> interested in doing some work on the road network in Brazil on
> OpenStreetMap, things like adding missing roads, making sure roads connect
> properly, fixing incorrect alignments with GPS traces, ensuring road
> classifications are consistent, and other similar issues.
>
> Are there places you know of that need improvement or types of problems
> you see frequently? Also I saw these guidelines about road classifications,
> are they the most recent classifications used by the community, or are
> there any others we should be aware of?
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a
>
> We have a Github page here about the project:
> https://github.com/osmlab/appledata/issues/126
>
> Please let me know if you have any suggestions or feedback.
>
> Thank you,
> Andrew
> Apple, Inc.
>
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Road network improvements in Brazil

[Fernando Trebien]

Hi Andrew.

As usual, the only questions I have are about highway classification.
In GitHub this is not yet detailed, so I'm wondering if you're
planning to follow a topological approach, as proposed and accepted
for the southernmost state. We know that that flowchart from 2013 is
not quite satisfactory. On the other hand, we know that, without
discussion, local mappers may not accept the results. What worked
really well for the southernmost state was to present the results
before making any changes to the map, then discussion to reach
consensus.

Regards,

Fernando Trebien

On Thu, Jul 11, 2019 at 1:41 PM Andrew Wiseman por (Talk-br)
 wrote:
>
> Hi OSM Brazil,
>
> This is Andrew again from the Maps team at Apple, a few months ago I wrote 
> that we were planning to start a project improving the road network in 
> Brazil, things like adding missing roads, making sure roads connect properly, 
> fixing incorrect alignments with GPS traces, ensuring road classifications 
> are consistent, and other similar issues. Thank you for your feedback then, 
> we incorporated it into our project.
>
> We did some analysis and plan to start in the North and Northeast regions of 
> the country. I wanted to see if you had any suggestions for places that might 
> have errors or have missing roads, or other issues in that area. There is 
> more information about our project here: 
> https://github.com/osmlab/appledata/issues/126
>
> Thank you,
>
> Andrew
>
> Apple, Inc.
>
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
> On Nov 9, 2018, at 11:37 AM, Andrew Wiseman  wrote:
>
> Hello OSM Brazil,
>
> My name is Andrew Wiseman, I work for Apple on the Maps team. My team is 
> interested in doing some work on the road network in Brazil on OpenStreetMap, 
> things like adding missing roads, making sure roads connect properly, fixing 
> incorrect alignments with GPS traces, ensuring road classifications are 
> consistent, and other similar issues.
>
> Are there places you know of that need improvement or types of problems you 
> see frequently? Also I saw these guidelines about road classifications, are 
> they the most recent classifications used by the community, or are there any 
> others we should be aware of? 
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a
>
> We have a Github page here about the project: 
> https://github.com/osmlab/appledata/issues/126
>
> Please let me know if you have any suggestions or feedback.
>
> Thank you,
> Andrew
> Apple, Inc.
>
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br



-- 
Fernando Trebien

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

Re: [Talk-br] Road network improvements in Brazil

[Andrew Wiseman por (Talk-br)]

Hi OSM Brazil,

This is Andrew again from the Maps team at Apple, a few months ago I wrote that 
we were planning to start a project improving the road network in Brazil, 
things like adding missing roads, making sure roads connect properly, fixing 
incorrect alignments with GPS traces, ensuring road classifications are 
consistent, and other similar issues. Thank you for your feedback then, we 
incorporated it into our project. 

We did some analysis and plan to start in the North and Northeast regions of 
the country. I wanted to see if you had any suggestions for places that might 
have errors or have missing roads, or other issues in that area. There is more 
information about our project here: 
https://github.com/osmlab/appledata/issues/126 


Thank you,

Andrew 

Apple, Inc.


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


> On Nov 9, 2018, at 11:37 AM, Andrew Wiseman  wrote:
> 
> Hello OSM Brazil,
> 
> My name is Andrew Wiseman, I work for Apple on the Maps team. My team is 
> interested in doing some work on the road network in Brazil on OpenStreetMap, 
> things like adding missing roads, making sure roads connect properly, fixing 
> incorrect alignments with GPS traces, ensuring road classifications are 
> consistent, and other similar issues. 
> 
> Are there places you know of that need improvement or types of problems you 
> see frequently? Also I saw these guidelines about road classifications, are 
> they the most recent classifications used by the community, or are there any 
> others we should be aware of? 
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a 
> 
> 
> We have a Github page here about the project: 
> https://github.com/osmlab/appledata/issues/126 
> 
> 
> Please let me know if you have any suggestions or feedback.
> 
> Thank you,
> Andrew
> Apple, Inc.
> 
> 
> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
> 
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Am Do., 11. Juli 2019 um 17:10 Uhr schrieb Andreas :

> Am 11.07.19 um 16:52 schrieb Johann Haag:
> >
> >
> > Am Do., 11. Juli 2019 um 16:36 Uhr schrieb Thomas Rupprecht
> > mailto:rupprecht.tho...@gmail.com>>:
> >
> > Bitte leite diese wichtige Information an Luzandro weiter. Es
> > ergibt sich daraus ein eine einfache Möglichkeit, diese Problem
> > Adressen auch nachträglich in OSM gezielt zu identifizieren und
> > sauber zu entfernen.
> >
> > Das wäre deine Aufgabe gewesen und nicht Luzandro's.
> >
> >
> > Ganz ehrlich, ich würde auch nicht auf die Idee kommen, den Austria
> > Addresshelper zu disassemblen.
> > Dein Hinweis ist aber sehr wertvoll, eröffnet dieser doch nun einen
> > interessanten Weg, die Adress Qualität -speziell im Osten von
> > Österreich- viel besser zu machen.
>
> Dies sollte vorher aber überprüft werden, dass war jetzt eine
> Bauchschätzung von mir.
>
> Hab mir das nochmal angeschaut und es dürfte aus dem Attribut
> "GNR_ADRESSE" ablesbar sein.
>
> Aber wie gesagt, vorher die Daten anschauen und dann die Schlüsse daraus
> ziehen.
>
> Sorry an alle anderen ML-Leser. Höre jetzt schon auf hier meinen Senf
> abzugeben, denn das Thema ist jetzt schon mehr als reichlich diskutiert
> worden.
>

Danke Andreas, das wahr wohl die produktivste Konversation seit langem.
Grüße Johann


>
> lg
> geologist
>
> > Lg Johann
> >
> >
> > mfg Thomas Rupprecht
> >
> >
> > Am Do., 11. Juli 2019 um 16:18 Uhr schrieb Johann Haag
> > mailto:johannh...@hxg.at>>:
> >
> >
> >
> > Am Do., 11. Juli 2019 um 16:05 Uhr schrieb Andreas
> > mailto:a_v...@gmx.at>>:
> >
> > Am 11.07.19 um 15:19 schrieb Johann Haag:
> > > In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein
> > Problem.
> > > Ich gehe nun einen initiativen Weg, um zu prüfen ob wir
> > Zähl Adressen irgendwie systematisch los werden. Ideal wäre
> > ein Merker hierfür im BEV Satz. Sollte es uns gelingen, vom
> > BEV einen solchen Flag zu bekommen, so könnte man
> > anschließend diese gezielt ausfiltern und löschen. Ein
> > Revert macht leider auch viel nützliches kaputt.
> >
> > Hättest du eine Validierung der Adressdaten vorgenommen,
> > dann wäre dir
> > das Attribut "BESTIMMUNGSART" aufgefallen und da kann man
> > auf "Z"
> > filtern und vola sind die Zähladressen weg.
> >
> >
> > Bitte leite diese wichtige Information an Luzandro weiter. Es
> > ergibt sich daraus ein eine einfache Möglichkeit, diese Problem
> > Adressen auch nachträglich in OSM gezielt zu identifizieren und
> > sauber zu entfernen.
> > Danke für diesen wertvollen Hinweis.
> > Lg Johann
> >
> >
> > lg
> > geologist
> >
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
> >
> >
> > --
> > Elektronikermeister Johann Haag
> > Innsbruckerstraße 42
> > 6380 St. Johann in Tirol
> > ÖSTERREICH
> > Tel: +43 664/174 7414
> > Mailto:johannh...@hxg.at 
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
> >
> >
> > --
> > Elektronikermeister Johann Haag
> > Innsbruckerstraße 42
> > 6380 St. Johann in Tirol
> > ÖSTERREICH
> > Tel: +43 664/174 7414
> > Mailto:johannh...@hxg.at 
> >
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] tag AGRITURISMO CON CAMERE

[Carlo Stemberger]

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

Quindi (oltre agli altri tag):

tourism=guest_house

a cui si può aggiungere
guest_house=agritourism
rooms=*
ecc., vedi https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house

Ciao!

Carlo

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-es] Reflexiones sobre accesibilidad

[yo paseopor]

Buenas tardes. Os paso una conversación de Telegram de la que podeis
deducir mis reflexiones sobre accesibilidad después de una reunión muy
positiva con un profesor de la Universitat Politècnica de Catalunya. Las
fotografías las teneis adjuntas en esta dirección
https://imgur.com/a/BXxbvxo


 yopaseopor
Gente! creo que debemos empezar a definir un modelo de mapeo exhaustivo y
concreto a fin de homogeneizar nuestros mapeos. Desde la UPC se  felicita a
mapeos tan exhaustivos como el de Las Fuentes o el de Llefià, pero se pide
unificación (uno parte de etiquetas "positivas" para los cruces y otro de
etiquetas "negativas")
Por cierto, en breve tendremos al profesor de accesibilidad de Vilanova
entre nosotros.

Jose Luis Infante
yopaseopor
Gente! creo que debemos empezar a definir un modelo de mapeo exhaustivo y
concreto a fin de homogeneizar nuestros mapeos. Desde
?? Explica
yopaseopor
te explico
(estoy generando la información)

Jose Luis Infante
Miedo me das
yopaseopor
muahahahaha
este es tu excelente trabajo en tu barrio, Jose Luis
https://yopaseopor.github.io/accessibilitat/map/?map=vies=16=41.43907=2.22208=000B0TFFFTFF
[Foto]
es un ejemplo sobre aceras
Este es el excelente trabajo de la gente de Las Fuentes

Jose Luis Infante
Ajá... 樂:wink:
yopaseopor
https://yopaseopor.github.io/accessibilitat/map/?map=vies=17=41.64575=-0.86551=000B0FTFFTFFFTFF
[Foto]
Ves algo que te choque?

Jose Luis Infante
Entiendo lo que dices... Yo tengo etiquetadas las wheelchair = no y en ZGZ
tienen las que yes
yopaseopor
vale, entenderás entonces...que también faltan las "limited"
(por tener los 3 colores del semáforo, por decir algo)
pero ahora voy un poco más allá
[Foto]
https://yopaseopor.github.io/accessibilitat/map/?map=vies=17=41.64575=-0.86551=000B0FTFFTFFFTFFFTFF

Jose Luis Infante
Yo les tengo puesto incline a up o down... Estas podrían ser limited
yopaseopor
este es el excelente trabajo que "le falta " al equipo de Las Fuentes

Jose Luis Infante
Y el wheelchair:description
yopaseopor
y este es el que falta en tu barrio
https://yopaseopor.github.io/accessibilitat/map/?map=vies=16=41.43984=2.22133=000B0TFFFTFFFTFF
[Foto]

Jose Luis Infante
Jeje... Por defecto son accesibles
yopaseopor
(ya no me meto con los barrios que no tienen ni metidas las aceras, esos ni
salen en el mapa)

Jose Luis Infante
Pero entiendo que quieras ser exhaustivo
yopaseopor
Jose Luis Infante
Jeje... Por defecto son accesibles
en OSM el "por defecto" no existe
así tenemos calles que no sabemos qué sentido de circulación realmente
tienen, porque, por defecto son de doble sentido y ahora tenemos calles con
esa información "por defecto" , y calles de las que no tenemos esa
información con la misma apariencia, como para detectarlas
Ahora voy un pelín más allá

Jose Luis Infante

yopaseopor
[Foto]
https://yopaseopor.github.io/accessibilitat/map/?map=vies=17=41.64575=-0.86551=000B0FTFFTFFFTFF
Este es el trabajo de Las Fuentes a nivel de cruces, pasos de peatones
podríamos decir
[Foto]
Sin embargo en Llefià la cosa está un pelín más oscura

Jose Luis Infante
Protesto! Un poco más al suroeste hay unas cuantas :smile:
yopaseopor
Si miramos con un poco de más detalle veremos que aún hay más posibilidad
de datos, gracias a tu ingente tarea de meter todos los cruces
[Foto]
https://yopaseopor.github.io/accessibilitat/map/?map=vies=16=41.43907=2.22208=000B0TFFFTFF
[Foto]
en las Fuentes vemos que la situación también tiene de esto un poco, nodos
que sí, nodos que aún faltan (porque son tareas titánicas, aquí o allí)
y ahora voy a lo último

Jose Luis Infante
Dispara
yopaseopor
[Foto]
esto es un cruce mi ciudad, como veis el semáforo de circulación y el de
peatones están separados, donde deberían estar
pero si enfoco a esos semáforos de peatones, no tienen etiqueta de bordillo
es más, en la realidad puede ser que el bordillo esté antes o después que
el semáforo de peatones así que aún debería crear un nodo extra entre el
semáforo y el cruce, que debería coincidir con la acera real si me pusiera
a dibujar superficies
[Foto]
Como habeis visto, todos son etiquetajes que dan resultados buenos, todos
requieren mucho trabajo, y todos se muestran en el mapa, a cual más
exhaustivo, (porque no he mostrado escritas, por ejemplo las description
que tiene Jose Luis  en Llefià
[Foto]
Más de 400 descripciones, se dice pronto

Jose Luis Infante
Sí, es complejo. Yo por mi parte no pongo los semáforos peatonales
individualmente, sino en el nodo del crossing. En cuanto a los kerbs, está
el tema de ponerlos individuales o en el crossing. Depende del detalle que
queramos dar.
yopaseopor
El caso es que habeis visto una ensalada de datos fantástica, pero no hemos
sido capaces aún de aunar todo este trabajo en una sola manera de verlo,
que sea tan completa que nos valga a todos

Jose Luis Infante
Uno de los problemas que estoy teniendo con los pasos peatonales es que en
un lado hay pavimento táctil y en el otro 

Re: [Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Johann Haag]

Am Do., 11. Juli 2019 um 16:46 Uhr schrieb Andreas :

> Am 11.07.19 um 16:04 schrieb Johann Haag:
> >
> >
> > Am Do., 11. Juli 2019 um 15:55 Uhr schrieb Andreas  > >:
> >
> > Am 11.07.19 um 15:35 schrieb Johann Haag:
> > > In der systematischen Anwendung des Austria Addresshelpers, sowie
> > vom OSM User Luzandro aufbereiteten BEV Adressen, stoße ich nun an
> > eine unüberwindbare Grenze. Diese Grenze kann man in mangelhafter
> > Qualität der BEV Adressen umschreiben.
> >
> > Bitte unterlasse es, deine eigen Fehler beim Import auf das BEV
> > abzuwelzen. Wir haben dir mehrfach erklärt, dass es einen offiziellen
> > Workflow für Importe in OSM gibt und wenn der eingehalten wird,
> sollte
> >
> > Auf den Umstand dass BEV Adressen problembehaftet sind, wird inzwischen
> > vielfach hingewiesen.
> >
> > das kein Problem sein.
> >
> > Mangels aktueller Luftbilder ist das nicht möglich.
>
> Falsch, das Luftbild ist nicht die einzige Valdierungsmöglichkeit.
>
> >
> > Von mir daher -1, denn dann würden geprüfte Adressen auch gelöscht
> > werden.
> >
> > Ich gehe davon aus, dass anschließend einer notwendigen Lage Korrektur,
> > der BEV Merker zu entfernen ist.
> > Man kann aber leicht einen Filter erstellen, der prüft, ob die OSM-
> > Adress Lage,  jener der BEV Adress Position entspricht, so würden
> > regulierte Adressen vom Löschen verschont.
>
> Nein, da du die Annahme voraussetzt, dass alle BEV Daten falsch sind.
> Was ist mit den BEV Daten die von Mappern eintragen wurden, überprüft
> wurden und diese mit den original Positionen übereinstimmt?
>

Ich bin bekanntlich ein Freund von Adress Nodes, validierte Adressen werden
aber normalerweise in das Gebäude Polygon übertragen.
Ich finde den neuen Hinweis von Andreas interessant, wie man Zähl Adressen
auch so identifizieren und entfernen kann.

Eine interessante Variante ist auch, Importe -auch den Addresshelper-
künftig an ein aktuelles Luftbild zu binden. Also die Anwendung von BEV
Adress- Veröffentlichungen mit der Veröffentlichung der Luftbilder zu
synchronisieren.
Grüße Johann

>
> lg
> geologist
>
> > Lg Johann
> >
> >
> > lg
> > geologist
> >
> > >
> > > Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
> > > ___
> > > Talk-at mailing list
> > > Talk-at@openstreetmap.org 
> > > https://lists.openstreetmap.org/listinfo/talk-at
> > >
> >
> >
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
> >
> >
> > --
> > Elektronikermeister Johann Haag
> > Innsbruckerstraße 42
> > 6380 St. Johann in Tirol
> > ÖSTERREICH
> > Tel: +43 664/174 7414
> > Mailto:johannh...@hxg.at 
> >
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Mapping rail trails

[stevea]

> Kevin Kenny wrote:
>> And route relations are important for sites like Waymarked Trails - 
>> it totally ignores walking and cycling routes that are not indicated 
>> with relations, which is why I wind up doing routes for even 
>> relatively trivial stuff like
>> https://www.openstreetmap.org/relation/4836600.(although 
>> that certainly meets Richard's five-mile threshold).

Richard Fairhurst  wrote:
> Ok. I've just finished a pass through CONUS relationising pretty much all
> the significant leisure trails I could find for which there weren't already
> route relations. HDYC is telling me that "recently" I've added 334 bike
> routes - I'm not sure what period that covers but it sounds about right.
> 
> By and large I've tagged them with network=lcn - there's certainly a case
> for upgrading some to =rcn but I'll leave that to those with local
> knowledge.
> 
> There's a bit of work still to do on smaller local trails that also form
> part of a longer route - e.g. parts of the Bay Trail, or the East Coast
> Greenway. It would be good to have a distinct C Canal Trail relation over
> and above the USBRS 50 relation, for example.

Having entered one (temporal) version of the ECG (full disclosure, 
Softworkers.com did so professionally), I agree with Richard that there are 
additional "smaller local trails that form part of a longer route."  Often 
these are spurs OFF OF the "main" route, although in other instances they 
superimpose at a different level (e.g. an lcn which shares infrastructure with 
an ncn).  Obviously it is important to "get the level right" when entering 
these, including entering two route relations if that is a reality in the world 
(an ncn AND an lcn).  The USA has firm methodologies by which we use these 
three (barely four, if you count international) levels.  The details are in our 
wikis:  https://wiki.osm.org/wiki/United_States/Bicycle_Networks (which links 
to https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System , our 
national / ncn network).

Please note that at a national level, ONLY numbered USBRs should be entered, 
and the process to do so is quite well-established.  Exceptionally (because of 
seriously large scope or importance) there are now also four "quasi-national" 
routes (up from two originally), which have emerged over the long term with 
wide (and sometimes fragile) consensus.  At state (rcn) and local (lcn) levels 
(the latter can include city-level and county-level), OSM consensus differs 
slightly state by state as to what "qualifies" to enter, but the bar is fairly 
high for all.  Briefly, if it is a government-sponsored route network, enter 
it, especially if signed.  For what appear to be "bike club" networks, think 
twice (or thrice) before entering these:  it is not usually the case that these 
are bona fide route networks, rather they are what a private group considers 
"good rides" and there are bazillions of these with which we do NOT wish to 
clutter the map.  Well-established rail trails which allow or are specifically 
designated for cyclists DO get a route relation (and please start, as Richard 
did, with network=lcn).

Also, there are proprietary routes (like ACA's routes, which are firmly 
discouraged from being entered as they are copyrighted), these should not be 
entered.  However, there is a tenet in OSM that "if you ride the route and 
acquire the track as a GPX, you have established legal nexus as a Contributor 
to enter these data into OSM."  If you do this, be careful that any name=* tag 
you enter is something you have permission to use, too.  This can be tricky if 
you think about it (why ride a ride and then be prevented from entering it AND 
its name because you don't have permission to use its name?).  However, simply 
"riding a ride" and then entering it as a route relation is highly discouraged: 
 bicycle route relations really are meant to express government-sponsored 
routes, rail trails and rarely, "quasi-private" routes (neither 
government-sanctioned nor approved by AASHTO, but public data, usually signed 
with proprietary signage).

There are state- (and even county-) level wikis which describe these "more 
regional" (or local) networks, California has at least four counties that I 
know of.  If you enter these routes / networks, you are highly encouraged to 
find the right place in our wiki-universe to enter at least a blurb that they 
exist.  Each and every state in the USA has a wiki and more and more of them 
are emerging to include a Bicycle Routes section.  Please, build up these wiki 
with such routes / networks!

As for rail trails, very nice work, Richard!  Rail trails are usually 
classified as local (lcn) if they are for cyclists, although some are sponsored 
at a state-level:  these are properly tagged rcn (regional generally means 
"state-level" in the USA).  I don't know this for sure (Minh?) but I might 
imagine that the C Canal Trail over and above the USBR 50 relation might be 
properly tagged rcn 

Re: [Talk-us] Mapping rail trails

[Phil! Gold]

* Richard Fairhurst  [2019-07-11 01:56 -0700]:
> It would be good to have a distinct C Canal Trail relation over and
> above the USBRS 50 relation, for example.

You mean aside from these?

  https://www.openstreetmap.org/relation/1392951
  https://www.openstreetmap.org/relation/9773990

I suppose it is a little silly to have a separate DC portion; I could just
go combine them into a single relation.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The Old Man and the Sea LITE(tm)
by Ernest Hemingway

An old man goes fishing, but doesn't have much luck.
 --- --

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

Re: [Talk-it] Problemi nella ricerca indirizzo con Maps.me

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 14:28, Vittorio Bertola via Talk-it 
>  wrote:
> 
> a meno che non ci si trovi a inizio frase nel qual caso la prima parola 
> diventa maiuscola e si ha "Monte Rosa";


Con ogni label inizia una frase.

Forse dovrebbe essere Monte rosa?
;-)


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

Re: [Talk-at] minderwertige Importe

[Andreas]

Am 11.07.19 um 16:35 schrieb Thomas Rupprecht:
> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt
> sich daraus ein eine einfache Möglichkeit, diese Problem Adressen
> auch nachträglich in OSM gezielt zu identifizieren und sauber zu
> entfernen.
> 
> Das wäre deine Aufgabe gewesen und nicht Luzandro's.

Dem kann ich nur zustimmen. Stehe nicht in Kontakt mit diesen Luzandro.
Man sollte sich vorher allerdings mal genauer die Spezifikation des
Datensatzes anschauen, das gehört nämlich auch zur Validierung von
Importdaten.

Ich habe nur kurz drüber geschaut und mir ist das Z aufgefallen, aber
das muss nicht unbedingt stimmen.

lg
geologist

> 
> mfg Thomas Rupprecht
> 
> 
> Am Do., 11. Juli 2019 um 16:18 Uhr schrieb Johann Haag
> mailto:johannh...@hxg.at>>:
> 
> 
> 
> Am Do., 11. Juli 2019 um 16:05 Uhr schrieb Andreas  >:
> 
> Am 11.07.19 um 15:19 schrieb Johann Haag:
> > In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein
> Problem.
> > Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl
> Adressen irgendwie systematisch los werden. Ideal wäre ein
> Merker hierfür im BEV Satz. Sollte es uns gelingen, vom BEV
> einen solchen Flag zu bekommen, so könnte man anschließend diese
> gezielt ausfiltern und löschen. Ein Revert macht leider auch
> viel nützliches kaputt.
> 
> Hättest du eine Validierung der Adressdaten vorgenommen, dann
> wäre dir
> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
> filtern und vola sind die Zähladressen weg.
> 
>  
> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt
> sich daraus ein eine einfache Möglichkeit, diese Problem Adressen
> auch nachträglich in OSM gezielt zu identifizieren und sauber zu
> entfernen.
> Danke für diesen wertvollen Hinweis.
> Lg Johann
> 
> 
> lg
> geologist
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> 
> -- 
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannh...@hxg.at 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




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

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Am Do., 11. Juli 2019 um 16:36 Uhr schrieb Thomas Rupprecht <
rupprecht.tho...@gmail.com>:

> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt sich
>> daraus ein eine einfache Möglichkeit, diese Problem Adressen auch
>> nachträglich in OSM gezielt zu identifizieren und sauber zu entfernen.
>>
> Das wäre deine Aufgabe gewesen und nicht Luzandro's.
>

Ganz ehrlich, ich würde auch nicht auf die Idee kommen, den Austria
Addresshelper zu disassemblen.
Dein Hinweis ist aber sehr wertvoll, eröffnet dieser doch nun einen
interessanten Weg, die Adress Qualität -speziell im Osten von Österreich-
viel besser zu machen.
Lg Johann


> mfg Thomas Rupprecht
>
>
> Am Do., 11. Juli 2019 um 16:18 Uhr schrieb Johann Haag  >:
>
>>
>>
>> Am Do., 11. Juli 2019 um 16:05 Uhr schrieb Andreas :
>>
>>> Am 11.07.19 um 15:19 schrieb Johann Haag:
>>> > In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
>>> > Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen
>>> irgendwie systematisch los werden. Ideal wäre ein Merker hierfür im BEV
>>> Satz. Sollte es uns gelingen, vom BEV einen solchen Flag zu bekommen, so
>>> könnte man anschließend diese gezielt ausfiltern und löschen. Ein Revert
>>> macht leider auch viel nützliches kaputt.
>>>
>>> Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
>>> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
>>> filtern und vola sind die Zähladressen weg.
>>>
>>
>> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt sich
>> daraus ein eine einfache Möglichkeit, diese Problem Adressen auch
>> nachträglich in OSM gezielt zu identifizieren und sauber zu entfernen.
>> Danke für diesen wertvollen Hinweis.
>> Lg Johann
>>
>>
>>> lg
>>> geologist
>>>
>>> ___
>>> Talk-at mailing list
>>> Talk-at@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-at
>>>
>>
>>
>> --
>> Elektronikermeister Johann Haag
>> Innsbruckerstraße 42
>> 6380 St. Johann in Tirol
>> ÖSTERREICH
>> Tel: +43 664/174 7414
>> Mailto:johannh...@hxg.at
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
>>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Flame su old_name

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 14:19, Vittorio Bertola via Talk-it 
>  wrote:
> 
> Venendo ai nomi fascisti in Piemonte in genere


quando feci il riferimento al fascismo non intendevo in Piemonte, pensavo più a 
casi come in Slovenia (che però non è nemmeno perfetto come esempio, perché 
storicamente anche molto “italiano”). Per esempio ci sono dei nomi tedeschi che 
erano in uso solo dal 1941 al 1945, e i posti non erano mai abitati da 
tedeschi, in questi casi mettere questo nome in old_name sarebbe abbastanza 
insensibile (anche perché gli abitanti di queste zone probabilmente spesso non 
hanno buoni ricordi dei tedeschi). Qualcuno lo aveva fatto comunque e a 
qualcun’altro non era piaciuto, e quindi ne avevamo parlato qualche anno fa nel 
forum tedesco.

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

Re: [Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Andreas]

Am 11.07.19 um 16:04 schrieb Johann Haag:
> 
> 
> Am Do., 11. Juli 2019 um 15:55 Uhr schrieb Andreas  >:
> 
> Am 11.07.19 um 15:35 schrieb Johann Haag:
> > In der systematischen Anwendung des Austria Addresshelpers, sowie
> vom OSM User Luzandro aufbereiteten BEV Adressen, stoße ich nun an
> eine unüberwindbare Grenze. Diese Grenze kann man in mangelhafter
> Qualität der BEV Adressen umschreiben.
> 
> Bitte unterlasse es, deine eigen Fehler beim Import auf das BEV
> abzuwelzen. Wir haben dir mehrfach erklärt, dass es einen offiziellen
> Workflow für Importe in OSM gibt und wenn der eingehalten wird, sollte
> 
> Auf den Umstand dass BEV Adressen problembehaftet sind, wird inzwischen
> vielfach hingewiesen.
> 
> das kein Problem sein.
> 
> Mangels aktueller Luftbilder ist das nicht möglich. 

Falsch, das Luftbild ist nicht die einzige Valdierungsmöglichkeit.

> 
> Von mir daher -1, denn dann würden geprüfte Adressen auch gelöscht
> werden.
> 
> Ich gehe davon aus, dass anschließend einer notwendigen Lage Korrektur,
> der BEV Merker zu entfernen ist.
> Man kann aber leicht einen Filter erstellen, der prüft, ob die OSM-
> Adress Lage,  jener der BEV Adress Position entspricht, so würden
> regulierte Adressen vom Löschen verschont.

Nein, da du die Annahme voraussetzt, dass alle BEV Daten falsch sind.
Was ist mit den BEV Daten die von Mappern eintragen wurden, überprüft
wurden und diese mit den original Positionen übereinstimmt?

lg
geologist

> Lg Johann
> 
> 
> lg
> geologist
> 
> >
> > Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> 
> -- 
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannh...@hxg.at 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




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

Re: [Talk-at] minderwertige Importe

[Thomas Rupprecht]

>
> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt sich
> daraus ein eine einfache Möglichkeit, diese Problem Adressen auch
> nachträglich in OSM gezielt zu identifizieren und sauber zu entfernen.
>
Das wäre deine Aufgabe gewesen und nicht Luzandro's.

mfg Thomas Rupprecht


Am Do., 11. Juli 2019 um 16:18 Uhr schrieb Johann Haag :

>
>
> Am Do., 11. Juli 2019 um 16:05 Uhr schrieb Andreas :
>
>> Am 11.07.19 um 15:19 schrieb Johann Haag:
>> > In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
>> > Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen
>> irgendwie systematisch los werden. Ideal wäre ein Merker hierfür im BEV
>> Satz. Sollte es uns gelingen, vom BEV einen solchen Flag zu bekommen, so
>> könnte man anschließend diese gezielt ausfiltern und löschen. Ein Revert
>> macht leider auch viel nützliches kaputt.
>>
>> Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
>> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
>> filtern und vola sind die Zähladressen weg.
>>
>
> Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt sich
> daraus ein eine einfache Möglichkeit, diese Problem Adressen auch
> nachträglich in OSM gezielt zu identifizieren und sauber zu entfernen.
> Danke für diesen wertvollen Hinweis.
> Lg Johann
>
>
>> lg
>> geologist
>>
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
>>
>
>
> --
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannh...@hxg.at
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] grèves Loire - résumé et conclusion ?

[François Boucault]

OK, donc en fait pas besoin de ces tags, puisque le wiki osm pointe déjà vers 
l'élément wikidata, et que celui-ci est lui-même relié à la page Wikipédia... 
ça simplifie !
Ps : lorsqu'on donne le tag wikidata dans l'éditeur id, il ajoute 
automatiquement le tag wikipédia
Merci pour l'aide :)

Le 11 juillet 2019 14:57:53 GMT+02:00, marc marc  a 
écrit :
>Bonjour,
>
>Le 11.07.19 à 14:30, François Boucault a écrit :
>> Pour un banc de sable avec peu ou pas de végétation : natural=shoal, 
>> seasonal=dry_season, 
>> wikidata=Q28337, wikipedia=fr:Banc de sable 
>
>wikidata/wikipedia sert à renseigner l'élément ou LA page
>qui parle de cet objet.
>mettre le même wikidata/wikipedia sur tous les bancs de sable ne va
>pas.
>soit tu met le wikidata sur la page wiki du tag (le plus courant)
>soit tu veux vraiment un wikidata sur l'objet, le wikidata ne
>concernant 
>que la description, cela reviendrait à inventer description:wikidata
>
>Cordialement,
>Marc
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Johann Haag]

Wichtiger Hinweis auf eine interessante Entwicklung:
https://lists.openstreetmap.org/pipermail/talk-at/2019-July/010056.html

Grüsse

Am Do., 11. Juli 2019 um 16:04 Uhr schrieb Johann Haag :

>
>
> Am Do., 11. Juli 2019 um 15:55 Uhr schrieb Andreas :
>
>> Am 11.07.19 um 15:35 schrieb Johann Haag:
>> > In der systematischen Anwendung des Austria Addresshelpers, sowie vom
>> OSM User Luzandro aufbereiteten BEV Adressen, stoße ich nun an eine
>> unüberwindbare Grenze. Diese Grenze kann man in mangelhafter Qualität der
>> BEV Adressen umschreiben.
>>
>> Bitte unterlasse es, deine eigen Fehler beim Import auf das BEV
>> abzuwelzen. Wir haben dir mehrfach erklärt, dass es einen offiziellen
>> Workflow für Importe in OSM gibt und wenn der eingehalten wird, sollte
>>
> Auf den Umstand dass BEV Adressen problembehaftet sind, wird inzwischen
> vielfach hingewiesen.
>
>> das kein Problem sein.
>>
> Mangels aktueller Luftbilder ist das nicht möglich.
>
>>
>> >
>> > Gravierende Probleme veranlassen mich nun leider, generell an der
>> Tauglichkeit der uns vom BEV zur Verfügung gestellten Adressen für
>> OpenStreetMap Zwecke zweifeln.
>>
>> Heureka!
>>
>> >
>> > Daher mein Antrag: Sämtliche Adressen mit Datenherkunft Bundesamt für
>> Eich und Vermessungswesen aus dem Projekt OpenStreetMap zu entfernen.
>>
>> Da gehst du davon aus, dass alle Mapper, die als "Datenherkunft
>> Bundesamt für Eich und Vermessungswesen" angegeben haben, die Daten von
>> BEV 1:1, wie du, importiert haben?
>
>
>> Von mir daher -1, denn dann würden geprüfte Adressen auch gelöscht werden.
>>
> Ich gehe davon aus, dass anschließend einer notwendigen Lage Korrektur,
> der BEV Merker zu entfernen ist.
> Man kann aber leicht einen Filter erstellen, der prüft, ob die OSM- Adress
> Lage,  jener der BEV Adress Position entspricht, so würden regulierte
> Adressen vom Löschen verschont.
> Lg Johann
>
>>
>> lg
>> geologist
>>
>> >
>> > Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
>> > ___
>> > Talk-at mailing list
>> > Talk-at@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-at
>> >
>>
>>
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
>>
>
>
> --
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannh...@hxg.at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Am Do., 11. Juli 2019 um 16:05 Uhr schrieb Andreas :

> Am 11.07.19 um 15:19 schrieb Johann Haag:
> > In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
> > Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen
> irgendwie systematisch los werden. Ideal wäre ein Merker hierfür im BEV
> Satz. Sollte es uns gelingen, vom BEV einen solchen Flag zu bekommen, so
> könnte man anschließend diese gezielt ausfiltern und löschen. Ein Revert
> macht leider auch viel nützliches kaputt.
>
> Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
> filtern und vola sind die Zähladressen weg.
>

Bitte leite diese wichtige Information an Luzandro weiter. Es ergibt sich
daraus ein eine einfache Möglichkeit, diese Problem Adressen auch
nachträglich in OSM gezielt zu identifizieren und sauber zu entfernen.
Danke für diesen wertvollen Hinweis.
Lg Johann


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


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Johann Haag]

Am Do., 11. Juli 2019 um 15:55 Uhr schrieb Andreas :

> Am 11.07.19 um 15:35 schrieb Johann Haag:
> > In der systematischen Anwendung des Austria Addresshelpers, sowie vom
> OSM User Luzandro aufbereiteten BEV Adressen, stoße ich nun an eine
> unüberwindbare Grenze. Diese Grenze kann man in mangelhafter Qualität der
> BEV Adressen umschreiben.
>
> Bitte unterlasse es, deine eigen Fehler beim Import auf das BEV
> abzuwelzen. Wir haben dir mehrfach erklärt, dass es einen offiziellen
> Workflow für Importe in OSM gibt und wenn der eingehalten wird, sollte
>
Auf den Umstand dass BEV Adressen problembehaftet sind, wird inzwischen
vielfach hingewiesen.

> das kein Problem sein.
>
Mangels aktueller Luftbilder ist das nicht möglich.

>
> >
> > Gravierende Probleme veranlassen mich nun leider, generell an der
> Tauglichkeit der uns vom BEV zur Verfügung gestellten Adressen für
> OpenStreetMap Zwecke zweifeln.
>
> Heureka!
>
> >
> > Daher mein Antrag: Sämtliche Adressen mit Datenherkunft Bundesamt für
> Eich und Vermessungswesen aus dem Projekt OpenStreetMap zu entfernen.
>
> Da gehst du davon aus, dass alle Mapper, die als "Datenherkunft
> Bundesamt für Eich und Vermessungswesen" angegeben haben, die Daten von
> BEV 1:1, wie du, importiert haben?


> Von mir daher -1, denn dann würden geprüfte Adressen auch gelöscht werden.
>
Ich gehe davon aus, dass anschließend einer notwendigen Lage Korrektur, der
BEV Merker zu entfernen ist.
Man kann aber leicht einen Filter erstellen, der prüft, ob die OSM- Adress
Lage,  jener der BEV Adress Position entspricht, so würden regulierte
Adressen vom Löschen verschont.
Lg Johann

>
> lg
> geologist
>
> >
> > Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
> > ___
> > Talk-at mailing list
> > Talk-at@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-at
> >
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] minderwertige Importe

[Andreas]

Am 11.07.19 um 15:19 schrieb Johann Haag:
> In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
> Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen 
> irgendwie systematisch los werden. Ideal wäre ein Merker hierfür im BEV Satz. 
> Sollte es uns gelingen, vom BEV einen solchen Flag zu bekommen, so könnte man 
> anschließend diese gezielt ausfiltern und löschen. Ein Revert macht leider 
> auch viel nützliches kaputt.

Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
filtern und vola sind die Zähladressen weg.

lg
geologist



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

Re: [OSM-talk] English wiki displaying partial alternate language

[Dave F via talk]

Aargh! Thanks

Is there a way to set language within a bookmarked URL to prevent this 
happening?


On 11/07/2019 14:47, Darafei "Komяpa" Praliaskouski wrote:

Please click on the wiki UI selector and not a link inside page:
[image: image.png]

On Thu, Jul 11, 2019 at 4:46 PM Dave F via talk 
wrote:


On 11/07/2019 14:18, Upliner wrote:

Do you see language switcher at the top near user name? Just select English
there and all will be fine.


Do you see 'English' is in *bold *meaning it's already selected?

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






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

Re: [Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Andreas]

Am 11.07.19 um 15:35 schrieb Johann Haag:
> In der systematischen Anwendung des Austria Addresshelpers, sowie vom OSM 
> User Luzandro aufbereiteten BEV Adressen, stoße ich nun an eine 
> unüberwindbare Grenze. Diese Grenze kann man in mangelhafter Qualität der BEV 
> Adressen umschreiben.

Bitte unterlasse es, deine eigen Fehler beim Import auf das BEV
abzuwelzen. Wir haben dir mehrfach erklärt, dass es einen offiziellen
Workflow für Importe in OSM gibt und wenn der eingehalten wird, sollte
das kein Problem sein.

> 
> Gravierende Probleme veranlassen mich nun leider, generell an der 
> Tauglichkeit der uns vom BEV zur Verfügung gestellten Adressen für 
> OpenStreetMap Zwecke zweifeln.

Heureka!

> 
> Daher mein Antrag: Sämtliche Adressen mit Datenherkunft Bundesamt für Eich 
> und Vermessungswesen aus dem Projekt OpenStreetMap zu entfernen.

Da gehst du davon aus, dass alle Mapper, die als "Datenherkunft
Bundesamt für Eich und Vermessungswesen" angegeben haben, die Daten von
BEV 1:1, wie du, importiert haben?

Von mir daher -1, denn dann würden geprüfte Adressen auch gelöscht werden.

lg
geologist

> 
> Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




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

Re: [OSM-talk] English wiki displaying partial alternate language

[Komяpa]

Please click on the wiki UI selector and not a link inside page:
[image: image.png]

On Thu, Jul 11, 2019 at 4:46 PM Dave F via talk 
wrote:

> On 11/07/2019 14:18, Upliner wrote:
>
> Do you see language switcher at the top near user name? Just select English
> there and all will be fine.
>
>
> Do you see 'English' is in *bold *meaning it's already selected?
>
> DaveF
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Am Do., 11. Juli 2019 um 15:40 Uhr schrieb Thomas Rupprecht <
rupprecht.tho...@gmail.com>:

> Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns
>> nichts an. Dann sollten wir aber so konsequent sein, und auch auf die uns
>> von dieser Seite zur Verfügung gestellten Luftbildern verzichten. Deren
>> veröffentlichung Rhytmous, nur alle drei Jahre, schränkt uns im Bestreben
>> eine Gold Karte zu schaffen nur unnötig ein.
>
> Du gehst jetzt wieder davon aus das jeder von der Karte einfach 1:1 abmalt
> ohne andere Referenzen (lokales wissen, Mapillary, Bing Maps, ...)
> heranzuziehen. Ich setze zb auf bestimmte OSM Objekte einen Hinweis dass
> das Orthofoto (so heißt das korrket) veraltet ist damit die gleichen Fehler
> nicht ständig wieder gemacht werden.
> Das gleiche wird (bzw sollte) auch bei den BEV Adressen gemacht werden:
> eine 2 Referenz heranziehen.
>
> Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man in der
>> Lage die Plausibilität von Adressen zu prüfen.
>>
> Du weißt schon dass ein "neues" Orthofoto meist schon wieder ein halbes
> Jahr oder so alt ist oder?
>
Hallo Thomas, da gebe ich dir natürlich Recht. In den BEV Daten steht aber
das genaue Stichtags Datum. das kann man ganz gut mit den Luftbildern in
Einklang bringen.
Ein gangbarer Weg, wäre daher, die Anwendung eines Importes an das Alter
des jeweiligen Luftbildes zu binden. Also BEV Adress Importe regional nur
jeweils genau nach Veröffentlichung eines neuen Luftbildes. Innerhalb der
Importfreien Zeit von etwa drei Jahren kann man gut lokales Wissen
einbinden. (Leider gibt aktuell Probleme mit der generellen BEV
Adressqualität)
Lg Johann


>
> mfg Thomas Rupprecht
>
>
> Am Do., 11. Juli 2019 um 14:14 Uhr schrieb Johann Haag  >:
>
>> Immerhin haben wir mit "Zähl Adressen“ ein reales Problem identifiziert.
>> Ein Problem welches nicht nur OpenStreetMap betrifft, sondern auch alle
>> anderen Kartensysteme sowie Navi Hersteller.
>>
>> Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns
>> nichts an. Dann sollten wir aber so konsequent sein, und auch auf die uns
>> von dieser Seite zur Verfügung gestellten Luftbildern verzichten. Deren
>> veröffentlichung Rhytmous, nur alle drei Jahre, schränkt uns im Bestreben
>> eine Gold Karte zu schaffen nur unnötig ein.
>>
>> Zwangsweise kommt es zwischen BEV Adressen und Luftbildern zu einer
>> Diskrepanz, wenn Adressen jährlich veröffentlicht werden, Luftbilder alle
>> drei Jahre.
>> Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten
>> anpassen. Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man
>> in der Lage die Plausibilität von Adressen zu prüfen. Die Behauptung hier,
>> dass importierte Adressen vielfach in der Landschaft liegen, kann man daher
>> erst mit dem nächsten Luftbild prüfen. Ein vorzeitiges Revert macht solches
>> Validierenden unmöglich.
>>
>> Daher, im Adress Satz ist das Veröffentlichung Datum enthalten, das Alter
>> des Luftbildes erkennt man am Wasserzeichen.
>> Grüße Johann
>>
>> > Am 11.07.2019 um 09:28 schrieb gppes_...@web.de:
>> >
>> > OSM hat mit Bauaemtern, Gemeinden und sonstigen oesterreichischen
>> offiziellen adressgenerierenden Stellen nichts zu tun.
>> >
>> > Ich werde Dein Ansinnen nicht unterstuetzen. Wir muessen dankbar sein,
>> dass wir die Adressen zur freien Nutzung bekommen. Wie die dort das
>> systematisch handhaben geht uns nichts an. OSM hat sein eigenes (teils
>> natuerlich in der Community aktiv diskutiertes) Konzept.
>> >
>> > Der User JM82 hat irgendwann mal im Forum geschrieben, dass das Melden
>> einzelner fehlerhafter Adressen (Fehler passieren halt mal ueberall)
>> konstruktiv behandelt wird. Meiner Erinnerung nach hat er also positive
>> Erfahrungen gemacht. Wen das genauer interessiert, der recherchiere dort.
>> >
>> > Aus meiner Sicht ist die AT OSM Community nicht zu instrumentalisieren,
>> irgendwelchen Aemtern (fragwuerdige) Verbesserungen ihrer Arbeitsmethoden
>> vorzuschlagen. Aus meiner Sicht kannst Du nicht im Namen von OSM (oder in
>> Verbindung mit OSM) dort Vorschlaege machen. Das ist aus meiner Sicht Dein
>> reines Privatvergnuegen.
>> >
>> > Lg, Gppes
>> >
>> >
>> >> Gesendet: Donnerstag, 11. Juli 2019 um 09:10 Uhr
>> >> Von: "Johann Haag" 
>> >> An: "OpenStreetMap AT" 
>> >> Betreff: Re: [Talk-at] minderwertige Importe
>> >>
>> >> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun
>> darum mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um
>> Mitwirkung an einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun
>> drei Wochen in Urlaub, anschliessend möchte ich mit dieser Initiative
>> beginnen.
>> >>
>> >> Grüsse Johann
>> >> Von meinem iPhone gesendet
>> >>
>> >>> Am 11.07.2019 um 08:26 schrieb Wolfgang Schreiter :
>> >>>
>> >>>
>> >>>
>> >>> Am 11.07.2019 06:42 schrieb Johann Haag:
>>  Die Adress- Situation im Osten von Österreich stellt sich
>>  folgendermaßen dar. Aus verwaltungstechnischen Gründen, 

Re: [OSM-talk] English wiki displaying partial alternate language

[Dave F via talk]

On 11/07/2019 14:18, Upliner wrote:

Do you see language switcher at the top near user name? Just select English
there and all will be fine.


Do you see 'English' is in *bold *meaning it's already selected?

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

Re: [Talk-at] minderwertige Importe

[Thomas Rupprecht]

>
> Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns
> nichts an. Dann sollten wir aber so konsequent sein, und auch auf die uns
> von dieser Seite zur Verfügung gestellten Luftbildern verzichten. Deren
> veröffentlichung Rhytmous, nur alle drei Jahre, schränkt uns im Bestreben
> eine Gold Karte zu schaffen nur unnötig ein.

Du gehst jetzt wieder davon aus das jeder von der Karte einfach 1:1 abmalt
ohne andere Referenzen (lokales wissen, Mapillary, Bing Maps, ...)
heranzuziehen. Ich setze zb auf bestimmte OSM Objekte einen Hinweis dass
das Orthofoto (so heißt das korrket) veraltet ist damit die gleichen Fehler
nicht ständig wieder gemacht werden.
Das gleiche wird (bzw sollte) auch bei den BEV Adressen gemacht werden:
eine 2 Referenz heranziehen.

Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man in der
> Lage die Plausibilität von Adressen zu prüfen.
>
Du weißt schon dass ein "neues" Orthofoto meist schon wieder ein halbes
Jahr oder so alt ist oder?

mfg Thomas Rupprecht


Am Do., 11. Juli 2019 um 14:14 Uhr schrieb Johann Haag :

> Immerhin haben wir mit "Zähl Adressen“ ein reales Problem identifiziert.
> Ein Problem welches nicht nur OpenStreetMap betrifft, sondern auch alle
> anderen Kartensysteme sowie Navi Hersteller.
>
> Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns
> nichts an. Dann sollten wir aber so konsequent sein, und auch auf die uns
> von dieser Seite zur Verfügung gestellten Luftbildern verzichten. Deren
> veröffentlichung Rhytmous, nur alle drei Jahre, schränkt uns im Bestreben
> eine Gold Karte zu schaffen nur unnötig ein.
>
> Zwangsweise kommt es zwischen BEV Adressen und Luftbildern zu einer
> Diskrepanz, wenn Adressen jährlich veröffentlicht werden, Luftbilder alle
> drei Jahre.
> Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten
> anpassen. Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man
> in der Lage die Plausibilität von Adressen zu prüfen. Die Behauptung hier,
> dass importierte Adressen vielfach in der Landschaft liegen, kann man daher
> erst mit dem nächsten Luftbild prüfen. Ein vorzeitiges Revert macht solches
> Validierenden unmöglich.
>
> Daher, im Adress Satz ist das Veröffentlichung Datum enthalten, das Alter
> des Luftbildes erkennt man am Wasserzeichen.
> Grüße Johann
>
> > Am 11.07.2019 um 09:28 schrieb gppes_...@web.de:
> >
> > OSM hat mit Bauaemtern, Gemeinden und sonstigen oesterreichischen
> offiziellen adressgenerierenden Stellen nichts zu tun.
> >
> > Ich werde Dein Ansinnen nicht unterstuetzen. Wir muessen dankbar sein,
> dass wir die Adressen zur freien Nutzung bekommen. Wie die dort das
> systematisch handhaben geht uns nichts an. OSM hat sein eigenes (teils
> natuerlich in der Community aktiv diskutiertes) Konzept.
> >
> > Der User JM82 hat irgendwann mal im Forum geschrieben, dass das Melden
> einzelner fehlerhafter Adressen (Fehler passieren halt mal ueberall)
> konstruktiv behandelt wird. Meiner Erinnerung nach hat er also positive
> Erfahrungen gemacht. Wen das genauer interessiert, der recherchiere dort.
> >
> > Aus meiner Sicht ist die AT OSM Community nicht zu instrumentalisieren,
> irgendwelchen Aemtern (fragwuerdige) Verbesserungen ihrer Arbeitsmethoden
> vorzuschlagen. Aus meiner Sicht kannst Du nicht im Namen von OSM (oder in
> Verbindung mit OSM) dort Vorschlaege machen. Das ist aus meiner Sicht Dein
> reines Privatvergnuegen.
> >
> > Lg, Gppes
> >
> >
> >> Gesendet: Donnerstag, 11. Juli 2019 um 09:10 Uhr
> >> Von: "Johann Haag" 
> >> An: "OpenStreetMap AT" 
> >> Betreff: Re: [Talk-at] minderwertige Importe
> >>
> >> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun
> darum mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um
> Mitwirkung an einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun
> drei Wochen in Urlaub, anschliessend möchte ich mit dieser Initiative
> beginnen.
> >>
> >> Grüsse Johann
> >> Von meinem iPhone gesendet
> >>
> >>> Am 11.07.2019 um 08:26 schrieb Wolfgang Schreiter :
> >>>
> >>>
> >>>
> >>> Am 11.07.2019 06:42 schrieb Johann Haag:
>  Die Adress- Situation im Osten von Österreich stellt sich
>  folgendermaßen dar. Aus verwaltungstechnischen Gründen, werden
>  Adressen von Gemeinden, bereits bei der Bauland Widmung in Form von
>  Zähl Adressen entlang der Straße vergeben. Anschließend kümmern
>  sich Gemeinden und Städte offensichtlich nur noch wenig darum.
> >>>
> >>> Mag sein. Ist aber kein Pronblem, solange die von den Gemeinden
> vergebenen Adressen nicht automatisch importiert, sondern von Mappern vor
> Ort überprüft werden.
> >>>
>  Ich
>  werde also nun Gemeinden systematisch anschreiben, und darum bitten,
>  dass dort wo es nun in unserem Projekt Adressen vollständig gibt.
>  Diese von den Bauämtern gesichtet und bereinigt werden.
> >>>
> >>> Das ändert nichts daran, dass wir uns nicht blind auf die Daten der
> Bauämter verlassen. Die Bauämter 

[Talk-at] Erfüllen BEV Adressen, den Qualitätsanspruch lokaler Datenerhebung, wie sich OpenStreetMap selbst definiert.

[Johann Haag]

In der systematischen Anwendung des Austria Addresshelpers, sowie vom OSM User 
Luzandro aufbereiteten BEV Adressen, stoße ich nun an eine unüberwindbare 
Grenze. Diese Grenze kann man in mangelhafter Qualität der BEV Adressen 
umschreiben.

Gravierende Probleme veranlassen mich nun leider, generell an der Tauglichkeit 
der uns vom BEV zur Verfügung gestellten Adressen für OpenStreetMap Zwecke 
zweifeln.

Daher mein Antrag: Sämtliche Adressen mit Datenherkunft Bundesamt für Eich und 
Vermessungswesen aus dem Projekt OpenStreetMap zu entfernen.

Lg Johann Haag, Ehrenamtlicher Mapper St. Johann in Tirol
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Handy-App führte Wanderer in Absturzgefahr

[Werner Macho]

Nein

On 11 July 2019 14:29:43 Johann Haag  wrote:


Handy-App führte Wanderer in Absturzgefahr
In Leogang (Pinzgau) haben Bergretter in der Nacht auf Donnerstag zwei 
junge Deutsche aus den Steinbergen gerettet. Die Wanderer benutzten eine 
Smartphone-App für die Wegsuche und gerieten in gefährliches Steilgelände.


Quelle: https://salzburg.orf.at/stories/3004115/

Die Bergrettung schreibt hingegen 
https://www.bergrettung-salzburg.at/news/news-detail/naechtliche-suchaktion-in-leoganger-steinbergen-nach-zwei-verirrten-burschen/

der Weg sei zwar existierend, durch hartes Eis aber unbegehbar.

Frage: ist ein Routen Ersteller, verantwortlich für eine jahreszeitlich 
möglicherweise Unbegehbarkeit.


Lg Johann
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at





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

Re: [Talk-at] minderwertige Importe

[Johann Haag]

In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen
irgendwie systematisch los werden. Ideal wäre ein Merker hierfür im BEV
Satz. Sollte es uns gelingen, vom BEV einen solchen Flag zu bekommen, so
könnte man anschließend solche Probleme gezielt ausfiltern und löschen. Ein
Revert macht leider auch viel nützliches kaputt.
Sollte vom BEV aber ein Nein kommen, dann ist es wohl notwendig sämtliche
BEV Adressen aus unserem Projekt zu entfernen.
Lg Johann

Am Do., 11. Juli 2019 um 15:04 Uhr schrieb :

> > Gesendet: Donnerstag, 11. Juli 2019 um 14:34 Uhr
> > Von: "Johann Haag" 
> > An: "OpenStreetMap AT" 
> > Betreff: Re: [Talk-at] minderwertige Importe
>
> > [...] zwischen BEV Adressen und Luftbildern zu einer
> > Diskrepanz, wenn Adressen jährlich veröffentlicht werden, Luftbilder aber
> > nur alle drei Jahre.
> > [...]
> > importierte Adressen vielfach in der Landschaft liegen, kann man daher
> erst
> > nach Vorlage eines aktuellen Luftbildes prüfen. Ein vorzeitiges Revert
> > macht solches Validierenden unmöglich.
>
> Leider Nein: Die BEV-Daten, die Tools zur Nutzung der BEV-Daten und die
> Luftbilder sind nur Hilfsmittel fuer den Mapper um mit der noetigen
> Sorgfalt Features in OSM einzutragen.
>
> Ein Import ist und war nie erwuenscht.
>
> Der Umkehrschluss, auf einen "Luftbildbeweis" warten zu muessen, gilt also
> nicht.
>
> Lg, Gppes
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] English wiki displaying partial alternate language

[Upliner]

Do you see language switcher at the top near user name? Just select English
there and all will be fine.

On Thu, Jul 11, 2019 at 4:12 PM Dave F via talk 
wrote:

> Hi
>
> https://wiki.openstreetmap.org/wiki/Main_Page
>
> Anybody else getting partial alternate language? (Slovenian?)
>
> https://snag.gy/TlcrxQ.jpg
>
> DaveF
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Best regards,
Upliner
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-at] minderwertige Importe

[Johann Haag]

In Gegenden mit Zähl Adressen sehe ich nun tatsächlich ein Problem.
Ich gehe nun einen initiativen Weg, um zu prüfen ob wir Zähl Adressen irgendwie 
systematisch los werden. Ideal wäre ein Merker hierfür im BEV Satz. Sollte es 
uns gelingen, vom BEV einen solchen Flag zu bekommen, so könnte man 
anschließend diese gezielt ausfiltern und löschen. Ein Revert macht leider auch 
viel nützliches kaputt.
Sollte vom BEV aber ein Nein kommen, dann ist es wohl notwendig sämtliche BEV 
Adressen aus unserem Projekt zu entfernen.
Lg Johann

> Am 11.07.2019 um 15:07 schrieb Andreas :
> 
> Am 11.07.19 um 09:10 schrieb Johann Haag:
>> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun darum 
>> mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um Mitwirkung an 
>> einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun drei Wochen in 
>> Urlaub, anschliessend möchte ich mit dieser Initiative beginnen.
> 
> Sehe ich das jetzt richtig, Community hat jetzt ein Zeitfenster von 3
> Wochen für den Revert?
> 
> lg
> geologist
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at


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

Re: [Talk-at] minderwertige Importe

[various]

Korrekt. 

Er ist gerade im "Ich gehe auf Urlaub, ihr macht das jetzt mal fertig, bis ich 
wieder da bin." Wo kämen wir denn hin, wenn er selbst zumindest eine erste 
Version geliefert hätte. (Keine Angst Johann, brauchst du nicht und ich hoffe, 
du wirst niemand im Namen von OSM anschreiben). + er ist gerade gesperrt und 
kann sowieso nichts machen.

Aber Frederik Ramm hat eigentlich auch angeboten, dass das seitens der DWG 
gemacht wird. Sollte ja einfach sein, Begründung ist ja immerhin "Unabgeklärter 
Import." Und noch dazu schlecht gemacht. Aber wenn die DWG das nicht machen 
will, dann muss eben die Community selbst ran, wie es aussieht.

> Andreas  hat am 11. Juli 2019 um 15:07 geschrieben:
> 
> Am 11.07.19 um 09:10 schrieb Johann Haag:> Adress Sätze von Luzandro sind 
> bekanntlich erschöpft. Es geht also nun darum mit dem Vorhandenem etwas 
> sinnvolles anzufangen. Also bitte um Mitwirkung an einem Mustertext zur 
> Aktivierung der Gemeinden . Ich bin nun drei Wochen in Urlaub, anschliessend 
> möchte ich mit dieser Initiative beginnen.Sehe ich das jetzt richtig, 
> Community hat jetzt ein Zeitfenster von 3Wochen für den Revert?
> lggeologist
> ___Talk-at mailing 
> listtalk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-at] Wie weiter mit dem Troll?

[gppes_osm--- via Talk-at]

Ich bin da aehnlicher Meinung wie Du.

Verstoesse gegen die Netiquette -> Ahndung.

Gleiches sehe ich aber bei wiederholtem kundtun der selben Meinung in der 
Hoffnung, dass man damit jemanden durch Quantitaet ueberzeugen koennte.

Im AT Forum wurden schon - aus meiner Sicht zu Recht - temporaere Sperren 
verhaengt. Gibt es so etwas fuer die Mailingliste auch?

Lg, Gppes

> Gesendet: Donnerstag, 11. Juli 2019 um 10:42 Uhr
> Von: "Norbert Wenzel" 
> An: talk-at@openstreetmap.org
> Betreff: Re: [Talk-at] Wie weiter mit dem Troll?
>
> On 11.07.19 09:33, Florian Ledermann wrote:
> > ich wollte mal die Frage in den Raum stellen, wie die Mailingliste 
> > gedenkt mit der Situation umzugehen, dass eine Person hier 
> > kontinuierlich die Liste [...] missbraucht, [...]
> 
> Zur Info: ich bin ein Listenadmin. Ich mach das jetzt seit etwa 10 
> Jahren und hab erst ein einziges Mal aktiv moderiert (d.h. Mails von 
> bekannten Absendern nicht mehr automatisch durchgelassen). Und das war 
> wegen wiederholter, unsubstantiierter Anschuldigungen gegen Personen auf 
> der Liste.
> 
> Ich denke nicht, dass ich in meiner Funktion als Listenadmin hier, 
> abseits von direkten Netiquetteverstößen *auf der Liste*, eingreifen 
> sollte. Auch, weil es nichts daran ändern würde dass die Importe 
> durchgeführt werden und ein gesperrter User im Nachhinein sagen kann, er 
> habe versucht anzukündigen und zu diskutieren, aber er war ja 
> gesperrt/wurde ignoriert.
> 
> 
> Ich weiß nicht wie die Foundation das normalerweise handhabt, aber ich 
> denke wenn jemand beständig gegen die Regeln der Community arbeitet und 
> auch keinerlei Einsicht in Diskussionen erkennen lässt, dann ist so 
> jemand nicht für ein Communityprojekt geeignet.
> 
> Aber das ist ein Problem von OSM als Ganzem bzw. der Foundation und 
> nicht nur der Mailingliste hier.
> 
> 
> Für deine private Mailbox kann natürlich ein Filter, wie er von Stefan 
> vorgeschlagen wurde, zumindest dir persönlich Linderung verschaffen.
> 
> 
> lg,
> Norbert
> 
> PS: (Andere) Ansichten zur Rolle des Listenadmin können und sollen gerne 
> hier deponiert werden. Wenn es einen Konsens hier gibt, leg ich meine 
> Rolle gerne entsprechend aus.
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

[OSM-talk] English wiki displaying partial alternate language

[Dave F via talk]

Hi

https://wiki.openstreetmap.org/wiki/Main_Page

Anybody else getting partial alternate language? (Slovenian?)

https://snag.gy/TlcrxQ.jpg

DaveF

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

Re: [Talk-at] minderwertige Importe

[Andreas]

Am 11.07.19 um 09:10 schrieb Johann Haag:
> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun darum 
> mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um Mitwirkung an 
> einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun drei Wochen in 
> Urlaub, anschliessend möchte ich mit dieser Initiative beginnen.

Sehe ich das jetzt richtig, Community hat jetzt ein Zeitfenster von 3
Wochen für den Revert?

lg
geologist



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

Re: [Talk-at] Wie weiter mit dem Troll?

[ScubbX]

Wer wäre bei einem Listenproblem der nächsthöhere Ansprechpartner?
Ist es die DWG? Ist Frederik R. dabei offiziell(er) eingebunden?


Am 11.07.19 um 10:42 schrieb Norbert Wenzel:

On 11.07.19 09:33, Florian Ledermann wrote:
ich wollte mal die Frage in den Raum stellen, wie die Mailingliste 
gedenkt mit der Situation umzugehen, dass eine Person hier 
kontinuierlich die Liste [...] missbraucht, [...]


Zur Info: ich bin ein Listenadmin. Ich mach das jetzt seit etwa 10 
Jahren und hab erst ein einziges Mal aktiv moderiert (d.h. Mails von 
bekannten Absendern nicht mehr automatisch durchgelassen). Und das war 
wegen wiederholter, unsubstantiierter Anschuldigungen gegen Personen 
auf der Liste.


Ich denke nicht, dass ich in meiner Funktion als Listenadmin hier, 
abseits von direkten Netiquetteverstößen *auf der Liste*, eingreifen 
sollte. Auch, weil es nichts daran ändern würde dass die Importe 
durchgeführt werden und ein gesperrter User im Nachhinein sagen kann, 
er habe versucht anzukündigen und zu diskutieren, aber er war ja 
gesperrt/wurde ignoriert.



Ich weiß nicht wie die Foundation das normalerweise handhabt, aber ich 
denke wenn jemand beständig gegen die Regeln der Community arbeitet 
und auch keinerlei Einsicht in Diskussionen erkennen lässt, dann ist 
so jemand nicht für ein Communityprojekt geeignet.


Aber das ist ein Problem von OSM als Ganzem bzw. der Foundation und 
nicht nur der Mailingliste hier.



Für deine private Mailbox kann natürlich ein Filter, wie er von Stefan 
vorgeschlagen wurde, zumindest dir persönlich Linderung verschaffen.



lg,
Norbert

PS: (Andere) Ansichten zur Rolle des Listenadmin können und sollen 
gerne hier deponiert werden. Wenn es einen Konsens hier gibt, leg ich 
meine Rolle gerne entsprechend aus.


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


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

Re: [OSM-talk-fr] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[osm . sanspourriel]

Assez d'accord avec Vincent.

Sur ma commune, des commerces réellement manquants. D'autres à vérifier.
Soit sur le terrain soit sur Pages Jaunes, Societe.com.

Je dis Pages Jaunes car si la société n'existe plus l'abonnement
téléphonique aura été terminé.

Par contre j'ai un terrain de camping en plein centre ville. Je suppose
que c'est le siège social ou un ancien terrain de camping. Pas de
résultat en faisant une recherche internet.

Comme Vincent j'ai un indice : le "Terrains de camping et parcs pour
caravanes ou véhicules de loisirs non intégré" n'a pas de nom.

Donc pas mal mais comme les boîtes-aux-lettres de la Poste, c'est une
aide, pas du clic-bouton et là non plus l'imagerie aérienne n'apporte rien.

Jean-Yvon


Le 10/07/2019 à 23:22, Frédéric Rodrigo - fred.rodr...@gmail.com a écrit :

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

Re: [OSRM-talk] Agnostic Map Matching profile

[André Siefken]

Ah man, I have been reviewing the bike profile, didn't see the
'weight_name' parameter examples in the car.lua...

Thx for the input, and your effort! I go explore some of your suggestions...



On 7/11/19 2:09 PM, Frédéric Rodrigo wrote:
> Le 11/07/2019 à 10:42, André Siefken a écrit :
>> Thx Frédéric for the immediate reply, and sorry for me to take my time
>> to respond.
>>
>> I will rewrite the profiles to test general soft restrictions, however
>> my idea here is to have a profile that e.g. strictly uses distance
>> between possible matched waypoints to get the overall match.
>
> Yes, you can active the distance as objective in the profile
>
> https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L19
>
>
>
>> How would the matching behave if I'd remove all road type based
>> restrictions (e.g. vehicle type allowed or not, speed limit, oneways)?
>
> To have soft restriction you must keep it with high weight.
>
>
> You can set this restricted road type into classes on profile, to
> select them dynamically on request
>
> See
>
> exclude     {class}[,{class}]     Additive list of classes to avoid,
> order does not matter.
>
> in
> https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#general-options
>
>
>> I do see where the algorithm needs certain base variables from the
>> network to estimate a likely route, though, and do have problems seeing
>> if this is feasonable at all, and I do ask instead of trying because it
>> will take me some time to get familiar with profile changes...
>>
>> André
>>
>> On 7/9/19 10:14 PM, Frédéric Rodrigo wrote:
>>> Le 09/07/2019 à 22:03, André Siefken a écrit :
 Hi @all,

 I'm exploring ways to have the matching algorithm work agnostic to
 (most) road restrictions and rather 'trust' the trace I pass in.

 I receive continuous GPS locations, with moderate to high
 resolution in
 time, from bikes as well as cabs or buses. It just so happens that
 some
 idiots ride their bikes on roads that OSM (and most laws) thinks they
 shouldn't, as well as some cars ignoring bus lane restrictions or
 buses
 leave their lanes. In those cases, matching fails one way or another
 ([No match], or only partial matches).

 I have a hard time wrapping my head around if a profile can actually
 fullfill restriction and/or even vehicle type (I can easily work with
 multiple graphs, though) agnostic matching, which likely implies a
 similar agnostic weighting. I imagine a shortest connection/path
 matching should do just that, but then I'm at a loss if that is
 actually
 the case and if so, how to generate such a profile.

 Your insights would be much appreciated...

 André
>>>
>>> I think the weighting is the right think to do. Use high weight on way
>>> there is no legal access. It's some kind of soft access restriction.
>>> You can even weight the opposite of a one way restriction.
>>>
>>> But you will have to rework all the samples profiles provided in OSRM.
>>>
>>>
>>> Frédéric.
>>>
>>>
>
-- 

pgp-key attached



0x0024705C4FC20AF6.asc
Description: application/pgp-keys
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-at] minderwertige Importe

[Andreas]

Am 11.07.19 um 14:34 schrieb Johann Haag:
> Immerhin haben wir mit "Zähl Adressen“ ein reales Problem
> identifiziert. Ein Problem welches nicht nur OpenStreetMap betrifft,
> sondern auch alle anderen Kartensysteme sowie Navi Hersteller.

Wahrscheinlich, aber ich sehe hier nicht als Aufgabe der OSM Community
hier für eine Lösung zu sorgen.

Außerdem nochmal, so was sollte in eine Validierung der Daten vor dem
Import überprüft werden und nach Ergebnis dann Import durchgeführt
werden, oder nicht!

> 
> Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht
> uns nichts an. Dann sollten wir aber so konsequent sein, und auch auf
> die uns von dieser Seite zur Verfügung gestellten Luftbildern
> verzichten.

Bitte keine Äpfel mit Birnen vergleichen.

> Deren Veröffentlichung Rhythmus, nur alle drei Jahre, schränkt uns
> im Bestreben eine Gold Karte zu schaffen nur unnötig ein.

Bitte, zeig mir einen Kartendienst der Luftbilder in der Aktualität von
3 Jahren in einer ähnlichen Auflösung anbietet.

Selbst Bing oder Google bieten keine häufigeren Aktualisierungen an.

> 
> Zwangsweise kommt es zwischen BEV Adressen und Luftbildern zu einer 
> Diskrepanz, wenn Adressen jährlich veröffentlicht werden, Luftbilder 
> aber nur alle drei Jahre.

Das Problem ist bei der Digitalisierung von Luftbildern nicht neu.

> Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten 
> anpassen. Ich handhabe das so, erst wenn ein neues Luftbild kommt,
> ist man in der Lage die Plausibilität von Adressen zu prüfen.

Bitte "Unsere" durch "Deine" ersetzen.

> dass importierte Adressen vielfach in der Landschaft liegen, kann
> man daher erst nach Vorlage eines aktuellen Luftbildes prüfen. Ein 
> vorzeitiges Revert macht solches Validierenden unmöglich.

Wenn du die ganze Diskussion dir nochmal durchliest, dann geht es bei
OSM darum, dass die Daten vor Ort, also in der Natur, validiert werden
und nicht nur per Luftbild.

Nochmal, weil es dir noch immer nicht klar ist: Besonderes Merkmal von
OSM ist, dass die Daten von Mappern vor Ort geprüft werden. Das
unterscheidet uns (OSM) von anderen Datenquellen.

> 
> Daher, im Adress Satz ist das Veröffentlichung Datum enthalten, das 
> Alter des Luftbildes erkennt man am Wasserzeichen. Beides muss man in
> der Bewertung berücksichtigen. Grüße Johann

Ja, hat aber meiner Meinung nach keinen Einfluss auf die Entscheidung
über den Revert des Imports. Der ist von anderen Mappern nicht nur
aufgrund von Luftbildern als mangelhaft kritisiert worden.

lg
geologist

> 
> Am Do., 11. Juli 2019 um 09:21 Uhr schrieb Andreas  >:
> 
> Am 11.07.19 um 08:26 schrieb Wolfgang Schreiter:
>> 
>> 
>> Am 11.07.2019 06:42 schrieb Johann Haag:
>>> Ich bitte also die Community hier um offizielle Unterstützung
>>> einer solchen Initiative. Unser gemeinsames Ziel ist sicher
>>> OpenStreetMap besser zu machen. Daher meine Bitte um Vorschläge
>>> für einen Mustertext.
>> 
>> Du ersuchst die Community um Unterstützung. Das setzt nicht nur 
>> Vertrauen in Deinen Vorschlag, sondern auch zu Dir als Mapper
>> voraus. Aktuell dreht sich die Diskussion darum, Teile Deiner
>> Imports
> rückgängig
>> zu machen und derartige (unabgestimmte, regelwidrige) Imports in
> Zukunft
>> gar nicht mehr zuzulassen (+1). Ich schlage vor, dass Du in Sachen 
>> Adressen zunächst einmal nichts Neues unternimmst, sondern
>> konstruktiv an der (manuellen) Behebung der vorhandenen Schäden
>> mitwirkst. Eine Nachdenkpause würde der Sache gut tun.
> 
> Auch +1 von mir. Das Ersuchen an die Community finde ich schon ein
> schön starkes Stück. Oder ist dein Plan, dass jetzt am Ende die
> Community schuld an den Adressen-Chaos ist, weil sie sich ja nicht
> bereit erklärt hat, den automatischen Import manuell nachzubessern?
> 
> Ich hätte da einen Vorschlag für die Zukunft:
> 
> Wenn du unbedingt OSM mit den OGD Adressdaten haben willst, kannst
> du dir gerne einen eigenen Server aufbauen. Dazu gibt es div.
> Anleitungen im Netz ua. https://switch2osm.org . Da kannst du dir
> dann die OGD Daten importieren, in deinem "freien" Blog beschreibst
> du wie du das gemacht hast, so bist du dann auch mit der OSM Lizenz
> konform.
> 
> Von Zeit zu Zeit kannst du dir ja die Updates von OSM in deine DB 
> reinimportieren, da gibt es auch schon etablierte Tools.
> 
> Und falls dir das Know-How dafür fehlt, kannst du ja deinen 
> ausgeschriebenen € 100,- Preis einen Supportdienstleister
> ausbezahlen, damit der dir die Sachen einrichtet.
> 
> Vorteil: Du hast für dich deine OSM mit deinen "vollständigen"
> Adressen und die offizielle OSM bleibt Datenmüll frei.
> 
> lg geologist
> 
> 
> ___ Talk-at mailing list 
> Talk-at@openstreetmap.org  
> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> 
> -- Elektronikermeister Johann Haag Innsbruckerstraße 42 6380 St.
> Johann in Tirol ÖSTERREICH Tel: +43 664/174 7414 
> Mailto:johannh...@hxg.at 

Re: [OSM-talk-fr] grèves Loire - résumé et conclusion ?

[marc marc]

Bonjour,

Le 11.07.19 à 14:30, François Boucault a écrit :
> Pour un banc de sable avec peu ou pas de végétation : natural=shoal, 
> seasonal=dry_season, 
> wikidata=Q28337, wikipedia=fr:Banc de sable 

wikidata/wikipedia sert à renseigner l'élément ou LA page
qui parle de cet objet.
mettre le même wikidata/wikipedia sur tous les bancs de sable ne va pas.
soit tu met le wikidata sur la page wiki du tag (le plus courant)
soit tu veux vraiment un wikidata sur l'objet, le wikidata ne concernant 
que la description, cela reviendrait à inventer description:wikidata

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

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Immerhin haben wir mit "Zähl Adressen“ ein reales Problem identifiziert.
Ein Problem welches nicht nur OpenStreetMap betrifft, sondern auch alle
anderen Kartensysteme sowie Navi Hersteller.

Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns
nichts an. Dann sollten wir aber so konsequent sein, und auch auf die uns
von dieser Seite zur Verfügung gestellten Luftbildern verzichten. Deren
Veröffentlichung Rhythmus, nur alle drei Jahre, schränkt uns im Bestreben
eine Gold Karte zu schaffen nur unnötig ein.

Zwangsweise kommt es zwischen BEV Adressen und Luftbildern zu einer
Diskrepanz, wenn Adressen jährlich veröffentlicht werden, Luftbilder aber
nur alle drei Jahre.
Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten
anpassen. Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man
in der Lage die Plausibilität von Adressen zu prüfen. Die Behauptung dass
importierte Adressen vielfach in der Landschaft liegen, kann man daher erst
nach Vorlage eines aktuellen Luftbildes prüfen. Ein vorzeitiges Revert
macht solches Validierenden unmöglich.

Daher, im Adress Satz ist das Veröffentlichung Datum enthalten, das Alter
des Luftbildes erkennt man am Wasserzeichen.
Beides muss man in der Bewertung berücksichtigen.
Grüße Johann

Am Do., 11. Juli 2019 um 09:21 Uhr schrieb Andreas :

> Am 11.07.19 um 08:26 schrieb Wolfgang Schreiter:
> >
> >
> > Am 11.07.2019 06:42 schrieb Johann Haag:
> >> Ich bitte also die Community hier um offizielle Unterstützung einer
> >> solchen Initiative. Unser gemeinsames Ziel ist sicher OpenStreetMap
> >> besser zu machen. Daher meine Bitte um Vorschläge für einen
> >> Mustertext.
> >
> > Du ersuchst die Community um Unterstützung. Das setzt nicht nur
> > Vertrauen in Deinen Vorschlag, sondern auch zu Dir als Mapper voraus.
> > Aktuell dreht sich die Diskussion darum, Teile Deiner Imports rückgängig
> > zu machen und derartige (unabgestimmte, regelwidrige) Imports in Zukunft
> > gar nicht mehr zuzulassen (+1). Ich schlage vor, dass Du in Sachen
> > Adressen zunächst einmal nichts Neues unternimmst, sondern konstruktiv
> > an der (manuellen) Behebung der vorhandenen Schäden mitwirkst. Eine
> > Nachdenkpause würde der Sache gut tun.
>
> Auch +1 von mir. Das Ersuchen an die Community finde ich schon ein schön
> starkes Stück. Oder ist dein Plan, dass jetzt am Ende die Community
> schuld an den Adressen-Chaos ist, weil sie sich ja nicht bereit erklärt
> hat, den automatischen Import manuell nachzubessern?
>
> Ich hätte da einen Vorschlag für die Zukunft:
>
> Wenn du unbedingt OSM mit den OGD Adressdaten haben willst, kannst du
> dir gerne einen eigenen Server aufbauen. Dazu gibt es div. Anleitungen
> im Netz ua. https://switch2osm.org . Da kannst du dir dann die OGD Daten
> importieren, in deinem "freien" Blog beschreibst du wie du das gemacht
> hast, so bist du dann auch mit der OSM Lizenz konform.
>
> Von Zeit zu Zeit kannst du dir ja die Updates von OSM in deine DB
> reinimportieren, da gibt es auch schon etablierte Tools.
>
> Und falls dir das Know-How dafür fehlt, kannst du ja deinen
> ausgeschriebenen € 100,- Preis einen Supportdienstleister ausbezahlen,
> damit der dir die Sachen einrichtet.
>
> Vorteil: Du hast für dich deine OSM mit deinen "vollständigen" Adressen
> und die offizielle OSM bleibt Datenmüll frei.
>
> lg
> geologist
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] grèves Loire - résumé et conclusion ?

[François Boucault]

Oups, j'ai envoyé trop vite, le dernier mail, je travaille encore dessus
et je le renvoie dans quelques jours... Désolé pour le spoil ;-)  ! 

Le 29/11/2018 à 09:38, Jérôme Seigneuret a écrit : 

> Pour faire plus simple tout les wetland=tidal_flat c'est uniquement en lien 
> avec les marais donc pas dans les terre chez nous sauf certains cours d'eau 
> on cela remonte comme sur la Gironde, Peut être la Dordogne, La Charante etc. 
> Les fleuves dans la montée des eau est impactée par les marées. La cote est 
> défini par un niveau de marée coef 120 par les anglais mais ne correspond pas 
> chez nous en terme de définition.  
> 
> Le niveau de définition du coastline est à 95 c'est un niveau qualifié de 
> "marée de vive eau" donc en marée haut sachant que les grande marée c'est à 
> partir de 100 à 120 sur notre échelle. 
> Le 0 terrestre comme on le connait c'est un 120 de marée.  
> 
> En exemple de prévision  sur le port de Camcalle dans la baie du Mont-Saint 
> Michel 
> 
> jour | heure | hauteur d'eau dans le port | coef de marée 
> 
> Mer.
> 05 00h10
> 05H27
> 12h34
> 17H48 2,69m
> 12,08M
> 2,61m
> 12,27M  
> 80
> 
> 83 
> 
> Sur ce port à un coef de marée de 95 on est à 13,29m.  
> 
> _D'un commun accord, la côte est marquée sur la ligne de pleine Mer Moyenne 
> de vives-eaux. Le MHWS en anglais correspondant au PMVE en France, environ 
> coef.95. "Fondamentalement c'est la ligne la plus élevée de l'eau atteint 
> dans des circonstances normales." On peut noter que cette phrase traduite de 
> la page anglaise est fausse car le MHWS est une moyenne des grandes marée 
> (vives eaux) et ne peut donc être la plus haute marée qui s'appelle en 
> anglais la Highest Astronomical Tide: HAT. coef 120_ 
> _Traditionnellement la "Laisse de Mer" la plus visible sur les photographies 
> aérienne est considérée comme etant placée à peu pret sur le MHWS._ 
> _La frontière entre le sable humide et sec marque à peu près la ligne des 
> marées de vives-eaux_ 
> _La ligne des marées de mortes-eaux est la position de la marée basse. Il 
> n'existe actuellement aucun accord pour marquer cette ligne dans OSM._ 
> 
> Donc en dessus de cette ligne tu peux avoir du tidal_flat quand le coef est 
> plus bas et tu peux avoir du tidal flat au-dessus de la limite du costline 
> jusqu'à la ligne des base marée (coef non défini donc la ligne n'est pas 
> établie dans OSM) et tu peux aussi avoir du tidal flat au dessus de la ligne 
> (moins évident sur nos latitudes mais c'est plutôt saisonnier et sur du 
> mascaret) On a plutot l'habitude de mettre au dessus de la ligna 
> natural=beach (et non pas bitch [1]) et autre 
> 
> Si l'on reste sur weatland tu peux avoir une végétation maraicageuse sans 
> pour autant être dans la flotte. si c'est dans l'eau tidal=yes sinon tidal=no 
> la saisonnalité ça se gère si ton élément n'est visible que pendant une 
> certaine période 
> seasonal=spring/summer/autumn/winter/wet_season/dry_season/ autre clé à 
> définir mais pas discuter 
> printemps,été,automne,hiver, saison des pluies, saison sèche 
> 
> ---> Fin de précision sur l'usage de tidal_flat
> 
> Le riverbed c'est le lit de la rivière en hauteur d'eau normale. Le riverbank 
> s'est les berges en hauteur normal donc le riverbank c'est le contour et ton 
> riverber des surfaces dans ton cours d'eau pour qualifier le lit de ton cours 
> d'eau. 
> Maintenant le problème pour tous le monde. C'est quelle hauteur la hauteur 
> d'eau normal car pour tracer il faut une limite. On ne peut pas se baser sur 
> les eaux permanentes pour définir ces niveaux. 
> 
> Pour tous ce qui concerne les masses d'eau et les cours d'eau, tu peux 
> ajouter le phénomène intermittence. C'est valable sur water, waterway, spring 
> donc intermittent=yes 
> on ajoute seasonal si c'est lié à une saison particulière 
> 
> Ducoup si c'est le lit que tu qualifies n'utiles pas natural mais riverbed et 
> ce qui s'en suit en terme de qualificatif 
> 
> Le mer. 28 nov. 2018 à 19:20, ades  a écrit : 
> Je m'essayerai à une synthèse demain dans la matinée, ça devient un peu 
> confus, mais je ferai un effort...  ;-)  
> 
> si quelqu'un le fait avant, je ne me vexerais pas ;-)
> 
> Le 28 nov. 2018 à 14:50, Jérôme Seigneuret  a 
> écrit : 
> 
> oui pour le wetland mais pas pour des banc de sable. Wetland ce sont des 
> zones humides donc avec une possibilité d'assèchement temporaire mais qui 
> ducoup correspond à un couvert végétal plus ou moins dense en fonction du 
> type de végétation et non a un banc de sable. On ne peut donc pas considérer 
> ça comme un wetland surtout si c'est une grève. Si la grève est stabilisé 
> avec un développement végétatif je veux bien. 
> Dans le cas du wetland tidal c'est plus compliqué d'avoir un développement 
> végétatif car les marée et le mouvement d'eau empêche l'implantation. Le wiki 
> mentionne la limite cotière car c'est en lien avec la zone de mouvement 
> perpétuelle. La situation est ainsi. Un coup c'est sous l'eau un 

Re: [OSM-talk-fr] grèves Loire - résumé et conclusion ?

[François Boucault]

Après une pause de 6 mois dans cette discussion, je fais un point sur
les bancs de sable de la Loire. 

J'ai relu le fil de discussion, les pages wiki OSM, les définitions
Wikipédia et Wikidata, etc... 

Évidemment il n'y a pas de solution idéale pour cartographier ces zones
"entre deux eaux", mais avec le recul voici ce que je propose : 

- Cartographier ou pas ? 

Ces zones font entièrement partie des paysages de Loire, car elles sont
découverte environ la moitié de l'année, tous les ans. Leur dessin
permet donc de mieux rendre compte des formes et du fonctionnement du
Fleuve. 

- Comment cartographier ? 

* Vérifier sur différentes images satellites - ou par sa propre
expérience - que le banc de sable ne bouge pas trop, et ne dessiner que
les amorces qui semblent durer longtemps
* Dans les parties navigables (en aval de la Maine) et/ou stabilisées
(entre des épis de Loire), il faut s'attendre à moins de mouvement des
bancs que dans les autres zones
* Dessiner les polygones entre les berges de la Loire (en dehors du
lit du fleuve, les zones sont tagguées normalement car non soumise à
l'intermittence)

- Comment tagguer ? 

Le terme anglais "shoal" semble ne désigner que des bancs de sable
maritimes et le wiki OSM, écrit en anglais et assez succint, peut
laisser penser qu'il ne faut pas utiliser ce tag pour une rivière...
Mais dans d'autres langues, notamment sur la page wikidata, "shoal" est
assimilé à un banc de sable générique (sandbank) désignant également des
bancs de sables fluviaux (sur la page wikipedia française aussi, sur la
page anglaise on fait références à des bancs de sable d'embouchure) 

S'agissant de zones recouvertes annuellement par de l'eau, dépendant de
la saison, 

* Pour un banc de sable avec peu ou pas de végétation : natural=shoal,
seasonal=dry_season, wikidata=Q28337, wikipedia=fr:Banc de sable (la
description wikidata remplace efficacement les premières descriptions
que j'avais mises)
* Pour un banc de sable bien stabilisé (car placé plus haut, près des
berges et avec de la végétation) mais toujours recouvert d'eau à la
saison humide : natural=grassland, seasonal=dry_season, grassland=dune
* Pour une petite île stabilisé et visiblement hors d'eau depuis des
années, on taggue normalement sans oublier de donner le rôle "inner"
dans la relation "Rivière la Loire", et de rajouter : place=islet

- Problème de rendu 

* Actuellement,

Le 29/11/2018 à 09:38, Jérôme Seigneuret a écrit : 

> Pour faire plus simple tout les wetland=tidal_flat c'est uniquement en lien 
> avec les marais donc pas dans les terre chez nous sauf certains cours d'eau 
> on cela remonte comme sur la Gironde, Peut être la Dordogne, La Charante etc. 
> Les fleuves dans la montée des eau est impactée par les marées. La cote est 
> défini par un niveau de marée coef 120 par les anglais mais ne correspond pas 
> chez nous en terme de définition.  
> 
> Le niveau de définition du coastline est à 95 c'est un niveau qualifié de 
> "marée de vive eau" donc en marée haut sachant que les grande marée c'est à 
> partir de 100 à 120 sur notre échelle. 
> Le 0 terrestre comme on le connait c'est un 120 de marée.  
> 
> En exemple de prévision  sur le port de Camcalle dans la baie du Mont-Saint 
> Michel 
> 
> jour | heure | hauteur d'eau dans le port | coef de marée 
> 
> Mer.
> 05 00h10
> 05H27
> 12h34
> 17H48 2,69m
> 12,08M
> 2,61m
> 12,27M  
> 80
> 
> 83 
> 
> Sur ce port à un coef de marée de 95 on est à 13,29m.  
> 
> _D'un commun accord, la côte est marquée sur la ligne de pleine Mer Moyenne 
> de vives-eaux. Le MHWS en anglais correspondant au PMVE en France, environ 
> coef.95. "Fondamentalement c'est la ligne la plus élevée de l'eau atteint 
> dans des circonstances normales." On peut noter que cette phrase traduite de 
> la page anglaise est fausse car le MHWS est une moyenne des grandes marée 
> (vives eaux) et ne peut donc être la plus haute marée qui s'appelle en 
> anglais la Highest Astronomical Tide: HAT. coef 120_ 
> _Traditionnellement la "Laisse de Mer" la plus visible sur les photographies 
> aérienne est considérée comme etant placée à peu pret sur le MHWS._ 
> _La frontière entre le sable humide et sec marque à peu près la ligne des 
> marées de vives-eaux_ 
> _La ligne des marées de mortes-eaux est la position de la marée basse. Il 
> n'existe actuellement aucun accord pour marquer cette ligne dans OSM._ 
> 
> Donc en dessus de cette ligne tu peux avoir du tidal_flat quand le coef est 
> plus bas et tu peux avoir du tidal flat au-dessus de la limite du costline 
> jusqu'à la ligne des base marée (coef non défini donc la ligne n'est pas 
> établie dans OSM) et tu peux aussi avoir du tidal flat au dessus de la ligne 
> (moins évident sur nos latitudes mais c'est plutôt saisonnier et sur du 
> mascaret) On a plutot l'habitude de mettre au dessus de la ligna 
> natural=beach (et non pas bitch [1]) et autre 
> 
> Si l'on reste sur weatland tu peux 

[Talk-at] Handy-App führte Wanderer in Absturzgefahr

[Johann Haag]

Handy-App führte Wanderer in Absturzgefahr
In Leogang (Pinzgau) haben Bergretter in der Nacht auf Donnerstag zwei junge 
Deutsche aus den Steinbergen gerettet. Die Wanderer benutzten eine 
Smartphone-App für die Wegsuche und gerieten in gefährliches Steilgelände.

Quelle: https://salzburg.orf.at/stories/3004115/

Die Bergrettung schreibt hingegen 
https://www.bergrettung-salzburg.at/news/news-detail/naechtliche-suchaktion-in-leoganger-steinbergen-nach-zwei-verirrten-burschen/
 
der Weg sei zwar existierend, durch hartes Eis aber unbegehbar.

Frage: ist ein Routen Ersteller, verantwortlich für eine jahreszeitlich 
möglicherweise Unbegehbarkeit.

Lg Johann
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Problemi nella ricerca indirizzo con Maps.me

[Vittorio Bertola via Talk-it]

Il 2019-07-11 10:18 liste DOT girarsi AT posteo DOT eu ha scritto:


Ciao Martin,

il problema è che si tratta di vecchie scritte messe sule case con
placche di marmo o calcaree, scritte semplicemente:

VICOLO CHIUSO

per cui l'adeguamento a OSM dovrebbe essere Vicolo chiuso, poi se 
Chiuso

è un cognome, quà dovremmo riaccendere le vecchie discussioni sui
decreti comunali, che attualmente non sono disponibili online e quindi
non è possibile conoscere direttamente la volontà del Comune all'epoca.


Scusa se mi permetto:

http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/

L'ortografia dei toponimi in italiano è chiara, si scrive "monte Rosa" 
(minuscolo il nome comune, maiuscolo il nome proprio), a meno che non ci 
si trovi a inizio frase nel qual caso la prima parola diventa maiuscola 
e si ha "Monte Rosa"; è comunque ammissibile il maiuscolo nella prima 
parola anche a centro frase, ma certo non il minuscolo nella seconda. 
Questo è indipendente dal fatto che "rosa" sia un aggettivo e non il 
cognome di qualcuno, perché quando fa parte di un toponimo diviene il 
nome proprio dell'oggetto geografico che indica, e quindi acquista la 
maiuscola.


Nel caso specifico, "vicolo chiuso" non può essere il nome del vicolo, 
ma al massimo una scritta (odonomasticamente irrilevante) che informa 
che il vicolo non va da nessuna parte. Se invece è diventata il nome del 
vicolo, allora è certamente "vicolo Chiuso"; in altre parole, o la 
strada non ha nome o si chiama "vicolo Chiuso", ma "vicolo chiuso" 
sicuramente no.


Ciao,
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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

Re: [OSM-talk-fr] Camera 360

[Jean-Marc Liotier]

On Wed, July 10, 2019 8:21 pm, Francois Gouget wrote:
>
> des photos qui ont des timestamps différents (et une
> précision sub-seconde) mais exactement les mêmes
> coordonnées GPS.
>
> L'application Mapillary me fournit aussi un fichier GPX
> qui lui aussi contient des points consécutifs avec des
> timestamps différents mais exactement les mêmes
> coordonnées GPS.
>
> C'est là que je fait l'interpolation avec une version
> modifiée des scripts mapillary_tools

Donc Mapillary a tout ce qu'il faut pour interpoler correctement les
positions des photos entre deux relevés GPS... Il me semble qu'il devrait
le faire directement, non ?

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

Re: [Talk-it] Problemi nella ricerca indirizzo con Maps.me

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 11:18, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> per cui l'adeguamento a OSM dovrebbe essere Vicolo chiuso, poi se Chiuso
> è un cognome, quà dovremmo riaccendere le vecchie discussioni sui
> decreti comunali, che attualmente non sono disponibili online e quindi
> non è possibile conoscere direttamente la volontà del Comune all'epoca.


secondo te si tratta di una targa antica tipo noexit=yes oppure è diventato un 
nome proprio del vicolo?

Se il secondo, metterei name=Vicolo Chiuso altrimenti non andrebbe in name.

Simile a “Via delle Sette Chiese” dove sette chiese non sarebbe da mettere in 
maiuscolo, ma essendo il nome della via, sì.

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

Re: [Talk-it] Flame su old_name

[Vittorio Bertola via Talk-it]

Il 2019-07-11 06:28 solitone ha scritto:
On 10 Jul 2019, at 12:59, Vittorio Bertola via Talk-it 
 wrote:


Veramente, a Torino (dove vivo) ho praticamente sempre sentito 
chiamare il posto "Salice d'Ulzio". Se dici "andiamo a Sosdul" ti 
capiscono, ma suona strano (anche perché quelli che usano il nome 
ufficiale spesso lo pronunciano "Sàuze" come è scritto e come si 
pronuncia in piemontese e in francoprovenzale, e non come si pronuncia 
in francese).


Nessuno capisce “/sosd'ul/ perché non si pronuncia alla francese. Non
è un nome francese. Si pronuncia /’sauze/ /d’ulks/.


Peggio ancora: il nome ufficiale è talmente poco usato che nessuno sa 
nemmeno come si pronunci...


Questo anche perché la località è diventata nota come stazione 
invernale quando si chiamava Salice, per cui il nome si è poi 
tramandato di generazione in generazione, almeno nelle città in cui 
c'è gente che va a sciare da quelle parti. Quindi IMHO è senza alcun 
dubbio un alt_name (e peraltro non si capisce che fastidio dia).


Dà fastidio perché “Salice d’Ulzio” è un nome inesistente, e che non
c’entra nulla  col nome originale, che è stato imposto dal regime
fascista.


Io penso che la mappa debba riflettere l'uso comune e non l'ideologia 
del mappatore. Nell'uso comune, abbiamo una parte dei 1000 residenti di 
Sauze d'Oulx (quelli che non sono proprietari di seconde case che hanno 
preso lì la residenza per non pagare l'IMU) che usa il nome ufficiale, e 
abbiamo qualche centinaio di migliaia di persone in pianura che almeno 
in buona parte usano il nome italianizzato (questo nel parlato, nello 
scritto invece il nome ufficiale prevale nettamente).


A me interessa che se qualcuno di questi va su una mappa basata su OSM e 
cerca "Salice d'Ulzio" trovi immediatamente il posto senza tanti 
problemi; da questo punto di vista, normalmente le applicazioni 
includono nella ricerca (talvolta anche nel rendering) gli alt_name ma 
non gli old_name, e per questo credo che alt_name sia preferibile, 
privilegiando l'usabilità della mappa. Già l'ideologia impazza ogni 
volta che si parla di name, almeno gli alt_name dovrebbero servire a 
riportare i nomi di uso comune ancorché sgraditi a chi governa i nomi 
ufficiali.


Venendo ai nomi fascisti in Piemonte in genere: il problema è che alcuni 
sono rimasti sia come ufficiali che come uso comune (es. Caprie al posto 
di Chiavrie), altri sono stati riportati alla grafia originaria e sono 
rientrati come tali anche nell'uso (es. Venaus invece di Venalzio). Poi 
però ci sono un sacco di casi intermedi complicati, per esempio il 
Comune di (pre-1939) Leynì, italianizzato dal fascismo in Lèini, 
rinominato nel dopoguerra Leinì ma apparentemente solo informalmente, 
senza una delibera valida, per cui il ministero dell'Interno una decina 
di anni fa ha ribadito che il nome ufficiale è Lèini e questo è il nome 
che abbiamo su OSM, ma è un nome che non usa assolutamente nessuno, e 
tutti in Piemonte lo chiamano Leinì; risultato, se cerchi "Leinì" lo 
trovi su Geonames ma non su OSM. (Direi che devo andare a mettere un 
alt_name...)


Ulzio e Salice d'Ulzio sono proprio uno di questi casi intermedi: 
probabilmente per la difficoltà di un italofono nel capire come si 
scrive e si pronuncia "Oulx", i due nomi italianizzati sono rimasti 
nell'uso generale. Addirittura, diversi comuni della cintura di Torino 
hanno a tutt'oggi una "via Ulzio" invece che "via Oulx", spesso 
intitolata ex novo in zone urbanizzate solo negli ultimi 
venti-trent'anni (es. 
https://www.openstreetmap.org/way/471777471#map=16/45.0424/7.5163 ) - il 
che mi pare un'altra prova del fatto che il toponimo sia ampiamente di 
uso comune ancora oggi. Altro che "inesistente"...


Ultima cosa:


Riporto per l’ennesima volta la definizione di alt_name [1], in cui si
afferma che  il soggetto da considerare sono gli abitanti del posto
(locals), non i torinesi o i genovesi o gli stranieri:

This tag can be used when a street, river or any other feature has 
another official (or locally preferred name) but locals frequently 
refer to it by its abbreviated name, or by other names in local 
dialects (for which a language code is not enough selective), or the 
name has several alternative orthographies (possibly in other scripts) 
and even the orthography of the preferred name is uncertain.


E nessuno a Sauze usa Salice come nome alternativo.


Ma secondo te, uno di Torino non è "local" a Salice d'Ulzio? Magari uno 
di Torino che ha la seconda casa lì e ci viene regolarmente e dice 
"questo weekend vado a Salice"? E uno di Ulzio? Di Susa? Dove comincia 
la repubblica indipendente di Sauze d'Oulx? Mi pare veramente un 
approccio un po' poco costruttivo.


Ciao,
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Immerhin haben wir mit "Zähl Adressen“ ein reales Problem identifiziert. Ein 
Problem welches nicht nur OpenStreetMap betrifft, sondern auch alle anderen 
Kartensysteme sowie Navi Hersteller.

Wir können uns nun auf den Standpunkt stellen, was Ämter machen geht uns nichts 
an. Dann sollten wir aber so konsequent sein, und auch auf die uns von dieser 
Seite zur Verfügung gestellten Luftbildern verzichten. Deren veröffentlichung 
Rhytmous, nur alle drei Jahre, schränkt uns im Bestreben eine Gold Karte zu 
schaffen nur unnötig ein. 

Zwangsweise kommt es zwischen BEV Adressen und Luftbildern zu einer Diskrepanz, 
wenn Adressen jährlich veröffentlicht werden, Luftbilder alle drei Jahre. 
Unsere Gold Bestrebungen müssen wir wohl an die realen Gegebenheiten anpassen. 
Ich handhabe das so, erst wenn ein neues Luftbild kommt, ist man in der Lage 
die Plausibilität von Adressen zu prüfen. Die Behauptung hier, dass importierte 
Adressen vielfach in der Landschaft liegen, kann man daher erst mit dem 
nächsten Luftbild prüfen. Ein vorzeitiges Revert macht solches Validierenden 
unmöglich.

Daher, im Adress Satz ist das Veröffentlichung Datum enthalten, das Alter des 
Luftbildes erkennt man am Wasserzeichen.
Grüße Johann

> Am 11.07.2019 um 09:28 schrieb gppes_...@web.de:
> 
> OSM hat mit Bauaemtern, Gemeinden und sonstigen oesterreichischen offiziellen 
> adressgenerierenden Stellen nichts zu tun.
> 
> Ich werde Dein Ansinnen nicht unterstuetzen. Wir muessen dankbar sein, dass 
> wir die Adressen zur freien Nutzung bekommen. Wie die dort das systematisch 
> handhaben geht uns nichts an. OSM hat sein eigenes (teils natuerlich in der 
> Community aktiv diskutiertes) Konzept.
> 
> Der User JM82 hat irgendwann mal im Forum geschrieben, dass das Melden 
> einzelner fehlerhafter Adressen (Fehler passieren halt mal ueberall) 
> konstruktiv behandelt wird. Meiner Erinnerung nach hat er also positive 
> Erfahrungen gemacht. Wen das genauer interessiert, der recherchiere dort.
> 
> Aus meiner Sicht ist die AT OSM Community nicht zu instrumentalisieren, 
> irgendwelchen Aemtern (fragwuerdige) Verbesserungen ihrer Arbeitsmethoden 
> vorzuschlagen. Aus meiner Sicht kannst Du nicht im Namen von OSM (oder in 
> Verbindung mit OSM) dort Vorschlaege machen. Das ist aus meiner Sicht Dein 
> reines Privatvergnuegen.
> 
> Lg, Gppes
> 
> 
>> Gesendet: Donnerstag, 11. Juli 2019 um 09:10 Uhr
>> Von: "Johann Haag" 
>> An: "OpenStreetMap AT" 
>> Betreff: Re: [Talk-at] minderwertige Importe
>> 
>> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun darum 
>> mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um Mitwirkung an 
>> einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun drei Wochen in 
>> Urlaub, anschliessend möchte ich mit dieser Initiative beginnen.
>> 
>> Grüsse Johann
>> Von meinem iPhone gesendet
>> 
>>> Am 11.07.2019 um 08:26 schrieb Wolfgang Schreiter :
>>> 
>>> 
>>> 
>>> Am 11.07.2019 06:42 schrieb Johann Haag:
 Die Adress- Situation im Osten von Österreich stellt sich
 folgendermaßen dar. Aus verwaltungstechnischen Gründen, werden
 Adressen von Gemeinden, bereits bei der Bauland Widmung in Form von
 Zähl Adressen entlang der Straße vergeben. Anschließend kümmern
 sich Gemeinden und Städte offensichtlich nur noch wenig darum.
>>> 
>>> Mag sein. Ist aber kein Pronblem, solange die von den Gemeinden vergebenen 
>>> Adressen nicht automatisch importiert, sondern von Mappern vor Ort 
>>> überprüft werden.
>>> 
 Ich
 werde also nun Gemeinden systematisch anschreiben, und darum bitten,
 dass dort wo es nun in unserem Projekt Adressen vollständig gibt.
 Diese von den Bauämtern gesichtet und bereinigt werden.
>>> 
>>> Das ändert nichts daran, dass wir uns nicht blind auf die Daten der 
>>> Bauämter verlassen. Die Bauämter wissen, dass neu vergebene Adressen noch 
>>> bis zu einem gewissen Grad vorläufig sind. Die Unschärfe wird bewusst in 
>>> Kauf genommen und mit der Zeit korrigiert. Wo wir das zeitnaher/besser 
>>> können, liegt es an uns.
>>> 
 Ich bitte also die Community hier um offizielle Unterstützung einer
 solchen Initiative. Unser gemeinsames Ziel ist sicher OpenStreetMap
 besser zu machen. Daher meine Bitte um Vorschläge für einen
 Mustertext.
>>> 
>>> Du ersuchst die Community um Unterstützung. Das setzt nicht nur Vertrauen 
>>> in Deinen Vorschlag, sondern auch zu Dir als Mapper voraus. Aktuell dreht 
>>> sich die Diskussion darum, Teile Deiner Imports rückgängig zu machen und 
>>> derartige (unabgestimmte, regelwidrige) Imports in Zukunft gar nicht mehr 
>>> zuzulassen (+1). Ich schlage vor, dass Du in Sachen Adressen zunächst 
>>> einmal nichts Neues unternimmst, sondern konstruktiv an der (manuellen) 
>>> Behebung der vorhandenen Schäden mitwirkst. Eine Nachdenkpause würde der 
>>> Sache gut tun.
>>> 
>>> Grüße
>>> Wolfgang
>>> 
>>> 
>>> ___
>>> Talk-at mailing list
>>> 

Re: [OSRM-talk] Agnostic Map Matching profile

[Frédéric Rodrigo]

Le 11/07/2019 à 10:42, André Siefken a écrit :

Thx Frédéric for the immediate reply, and sorry for me to take my time
to respond.

I will rewrite the profiles to test general soft restrictions, however
my idea here is to have a profile that e.g. strictly uses distance
between possible matched waypoints to get the overall match.


Yes, you can active the distance as objective in the profile

https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L19



How would the matching behave if I'd remove all road type based
restrictions (e.g. vehicle type allowed or not, speed limit, oneways)?


To have soft restriction you must keep it with high weight.


You can set this restricted road type into classes on profile, to select 
them dynamically on request


See

exclude     {class}[,{class}]     Additive list of classes to avoid, 
order does not matter.


in 
https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#general-options




I do see where the algorithm needs certain base variables from the
network to estimate a likely route, though, and do have problems seeing
if this is feasonable at all, and I do ask instead of trying because it
will take me some time to get familiar with profile changes...

André

On 7/9/19 10:14 PM, Frédéric Rodrigo wrote:

Le 09/07/2019 à 22:03, André Siefken a écrit :

Hi @all,

I'm exploring ways to have the matching algorithm work agnostic to
(most) road restrictions and rather 'trust' the trace I pass in.

I receive continuous GPS locations, with moderate to high resolution in
time, from bikes as well as cabs or buses. It just so happens that some
idiots ride their bikes on roads that OSM (and most laws) thinks they
shouldn't, as well as some cars ignoring bus lane restrictions or buses
leave their lanes. In those cases, matching fails one way or another
([No match], or only partial matches).

I have a hard time wrapping my head around if a profile can actually
fullfill restriction and/or even vehicle type (I can easily work with
multiple graphs, though) agnostic matching, which likely implies a
similar agnostic weighting. I imagine a shortest connection/path
matching should do just that, but then I'm at a loss if that is actually
the case and if so, how to generate such a profile.

Your insights would be much appreciated...

André


I think the weighting is the right think to do. Use high weight on way
there is no legal access. It's some kind of soft access restriction.
You can even weight the opposite of a one way restriction.

But you will have to rework all the samples profiles provided in OSRM.


Frédéric.





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

Re: [Talk-GB] Tagging a St John's Ambulance base

[Ben Proctor]

Thanks both

On Wed, 10 Jul 2019 at 21:53, Peter Neale via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> ...Or, looking at their website, it is a charity, so perhaps that makes it
> a "social facility"?
>
> Oh BTW, it is "St John Ambulance", not "St John's Ambulance" (I don't know
> why, but it is...)
>
> See St John Ambulance - the nation’s leading first aid charity
> 
>
> St John Ambulance - the nation’s leading first aid charity
>
> First aid is a simple skill with an incredible impact. We want everyone to
> learn it, so that they can be the dif...
> 
>
> Regards,
> Peter Neale
> t: 01908 309666
> m: 07968 341930
> skype: nealepb
>
>
> On Wednesday, 10 July 2019, 21:20:36 BST, Peter Neale via Talk-GB <
> talk-gb@openstreetmap.org> wrote:
>
>
> Personally, I would have thought of it as a club, in which first aid is
> taught, as a hobby ( No offence intended to any St John volunteers)
>
> Peter
>
> Sent from Yahoo Mail on Android
> 
>
> On Wed, 10 Jul 2019 at 20:30, Mark Goodge
>  wrote:
>
>
> On 10/07/2019 19:08, Ben Proctor wrote:
> > Hello mapping people
> >
> > There is a building and yard in Hereford used by St John's Ambulance.
> > The building functions as a meeting venue (like a scout hut but for St
> > John's) and some vehicles are stored in the yard.
> >
> > https://www.openstreetmap.org/#map=19/52.06051/-2.71419
> >
> > How would you tag this?
> >
> > It's currently amenity=doctors which doesn't seem right.
> > emergency=ambulance_station doesn't seem to describe this use.
> >
> > I was heading down amenity=community_centre route but I'm not sure
> > that's right either.
> >
> > A quick search for St John's Ambulance reveals a wider range of
> > approaches in other areas.
>
> I'd be inclined to go for community centre, in this case. It isn't an
> emergency ambulance station, which is what the
> emergency=ambulance_station tag is for (and, in any case, is rapidly
> becoming obsolete with the new distributed means of organising an
> ambulance service), and it isn't a doctor or a clinic either. And the
> main purpose of the building (as opposed to the yard) is for things like
> first aid training (both for St John volunteers themselves and the wider
> community). So a community centre is probably closest.
>
> Mark
>
> Mark
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>


-- 
Ben Proctor, Technical Director

*The Satori Lab*, 22 Windsor Place Cardiff. CF10 3BY Wales, UK

b...@satorilab.org | @likeaword  | 07904 1234
98 | LinkedIn 

We help public servants with data, design and system change challenges
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

Du coup, je pense avoir trouver la solution.

Avec osm2pgsql, l'attribut timestamp n'est pas bien interprété si on utilise
les fichiers.osm.pbf. Il se trouve que cette attribut est au format texte et
qu'osm2pgsql n'arrive pas à l'exploiter. Du coup, en utilisant un
fichier.osm ça fonctionne bien.

Pour Frédéric, si je veux fusionner mes 2 scripts osmosis, je dois faire :
--rb fichier1.osm.pbf --rb fichier2.osm.pbf --rb fichier.osm.pbf --merge
--merge --bounding-box top=44.3 left=4.6 bottom=43.9 right=5.0
completeWays=yes completeRelations=yes --wx destination.osm

où je dois d'abord appliquer le --bounding-box top=44.3 left=4.6 bottom=43.9
right=5.0 completeWays=yes completeRelations=yes à chaque fichier.osm.pbf
avant de les fusionner ?



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSRM-talk] Agnostic Map Matching profile

[Mohamad Jarwan]

I have many problems on installing nominatim
can anyone help me to install nominatim on Linux server

i can give him server IP and username,password

thanks

On Thu, Jul 11, 2019 at 11:44 AM André Siefken  wrote:

> Thx Frédéric for the immediate reply, and sorry for me to take my time
> to respond.
>
> I will rewrite the profiles to test general soft restrictions, however
> my idea here is to have a profile that e.g. strictly uses distance
> between possible matched waypoints to get the overall match.
>
> How would the matching behave if I'd remove all road type based
> restrictions (e.g. vehicle type allowed or not, speed limit, oneways)?
>
> I do see where the algorithm needs certain base variables from the
> network to estimate a likely route, though, and do have problems seeing
> if this is feasonable at all, and I do ask instead of trying because it
> will take me some time to get familiar with profile changes...
>
> André
>
> On 7/9/19 10:14 PM, Frédéric Rodrigo wrote:
> > Le 09/07/2019 à 22:03, André Siefken a écrit :
> >> Hi @all,
> >>
> >> I'm exploring ways to have the matching algorithm work agnostic to
> >> (most) road restrictions and rather 'trust' the trace I pass in.
> >>
> >> I receive continuous GPS locations, with moderate to high resolution in
> >> time, from bikes as well as cabs or buses. It just so happens that some
> >> idiots ride their bikes on roads that OSM (and most laws) thinks they
> >> shouldn't, as well as some cars ignoring bus lane restrictions or buses
> >> leave their lanes. In those cases, matching fails one way or another
> >> ([No match], or only partial matches).
> >>
> >> I have a hard time wrapping my head around if a profile can actually
> >> fullfill restriction and/or even vehicle type (I can easily work with
> >> multiple graphs, though) agnostic matching, which likely implies a
> >> similar agnostic weighting. I imagine a shortest connection/path
> >> matching should do just that, but then I'm at a loss if that is actually
> >> the case and if so, how to generate such a profile.
> >>
> >> Your insights would be much appreciated...
> >>
> >> André
> >
> >
> > I think the weighting is the right think to do. Use high weight on way
> > there is no legal access. It's some kind of soft access restriction.
> > You can even weight the opposite of a one way restriction.
> >
> > But you will have to rework all the samples profiles provided in OSRM.
> >
> >
> > Frédéric.
> >
> >
> --
>
> pgp-key attached
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[Talk-it] tag AGRITURISMO CON CAMERE

[Roberto Brazzelli]

Ciao,
come si mappa un agriturismo con camere?
amenity=restaurant

e poi per segnalare la presenza di camere?

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

[Talk-hr] Objavljen digitalni ortofoto Državne geodetske uprave 2018

[hbogner]

https://osm-hr.org/2019/07/11/objavljen-digitalni-ortofoto-drzavne-geodetske-uprave-2018/

U prošlom tekstu objavljene su informacije o pravu korištenja mrežnih 
usluga prostornih podataka Državne geodetske uprave. Nakon objave tog 
teksta uočena je nova objava o službenoj uporabi DOF 2018. Članak 
prenosimo u cijelosti zbog arhivskih razloga:


Ravnatelj Državne geodetske uprave donio je Odluku o stavljanju u 
službenu uporabu 5415 listova digitalne ortofotokarte u mjerilu 1:5000 
(DOF5) – završno izdanje, za 50% područja Republike Hrvatske (zapadni dio).


Digitalne ortofoto karte izrađene su na temelju 
aerofotogrametrijskog snimanja 2018. godine u projekcijskom referentnom 
sustavu HTRS96/TM.


Odluku možete pročitati na poveznici, a nazive listova, 
nomenklature i godinu snimanja u privitku Odluke.


Gledajući kako su prethodni ortofoto slojevi dostupni za korištenje, 
identični uvjeti bi trebali važiti i za ovaj sloj.


Sloj 2018 je nadopunjuje sloj 2017 tako da kombinirajući ta dva sloja 
imamo novu pokrivenost RH. Ovo čini treću generaciju pokrivenosti RH 
dostupnu za OpenStreetMap korištenje, prva je 2011, druga je 2014-2016, 
te ova treća u dva odvojena sloja 2017-2018. Ako DGU u nekom trenutku 
objavi objedinjeni link objavit će se i ta informacija.


Potrebno je ručno upisati adresu u željeni editor:

Name= DGU-DOF-2018
URL= 
wms:https://geoportal.dgu.hr/services/inspire/orthophoto_2018/ows?SERVICE=WMS=image/png=TRUE=1.1.1=WMS=GetMap=OI.OrthoImagery=={proj}={width}={height}={bbox}

DGU-DOF-2018

Sretno mapiranje!


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

Re: [Talk-at] Wie weiter mit dem Troll?

[Andreas]

Am 11.07.19 um 09:33 schrieb Florian Ledermann:
> Wenn ihr es für richtig haltet die Person einfach nur zu ignorieren um
> das ganze nicht weiter anzuheizen ("don't feed the troll") dann verstehe
> ich das, dann ignoriert auch diese Mail gerne. Ich wollte euch nur
> wissen lassen, dass ich mich ernsthaft mit dem Gedanken spiele, die
> Liste zu verlassen.
>

Das ist schade, dass du deshalb deine Aktivitäten auf der ML einstellen
willst. Kann ich zum Teil verstehen, aber dann überlässt man ja
eigentlich die ML der Person.

Ich habe mich mit den Filtermöglichkeiten noch nicht so stark
beschäftigt und ich weiß ja auch nicht was für ein Programm du
verwendest, aber vielleicht gibt es da was, das du die Diskussionen die
dich nicht interessieren, du sie ausblenden kannst?

lg
Geologist

> Best Grüße,
> 
> Flo L.
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at




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

Re: [Talk-it] Problemi nella ricerca indirizzo con Maps.me

[liste DOT girarsi AT posteo DOT eu]

Il 11/07/19 11:01, Martin Koppenhoefer ha scritto:

> se il nome non fosse „Vicolo Chiuso“ non sarebbe da inserire nel tag “name”
> 
> È vero che “chiuso” è un aggettivo e non va scritto in maiuscolo, ma potrebbe 
> essere diventato anche un nome (nel caso di una via per esempio).
> 

Ciao Martin,

il problema è che si tratta di vecchie scritte messe sule case con
placche di marmo o calcaree, scritte semplicemente:

VICOLO CHIUSO

per cui l'adeguamento a OSM dovrebbe essere Vicolo chiuso, poi se Chiuso
è un cognome, quà dovremmo riaccendere le vecchie discussioni sui
decreti comunali, che attualmente non sono disponibili online e quindi
non è possibile conoscere direttamente la volontà del Comune all'epoca.


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-at] minderwertige Importe

[Johann Haag]

Leider liefert der BEV Satz, im Osten von Österreich auch Zähl Adressen aus. 
Das ist ein reales Problem. Daher auch meine Initiative, Gemeinden um 
Mitwirkung bei der Bereinigung zu bitten. Vielleicht ist es dem Verein möglich, 
beim BEV anzufragen, dass dieser Zähl Adressen bei künftigen OpenData Adress 
Sätzen ausspart. Uns wäre so wirklich geholfen. Auch Google und Co werden 
derzeit vom BEV mit diesen Zähl Adressen beglückt.
lg Johann 

Von meinem iPhone gesendet

> Am 11.07.2019 um 09:30 schrieb ScubbX :
> 
> (sorry,meine Antwort ging wieder nicht an die Liste, daher hier nochmals):
> 
> 
> Sind diese von dir genannten Zähladressen/Pseudoadressen Bestandteil der BEV 
> Stichtagsdaten?
> 
> Ist die Primärdirektive der OSM nicht, dass wir das mappen, was in der Natur 
> als wahr verifiziert werden kann?
> 
> Die OGD Adressdaten sollten meiner Meinung nach dazu ein Anhalt bzw eine 
> Ergänzung sein. Wenn ein Import ohne große Konflikte machbar ist, dann finde 
> ich das auch OK, aber den OGD Adressdatensatz als Goldstandard hernehmen und 
> die OSM danach zu modellieren, finde ich nicht ideal.
> Der Goldstandard für die OSM ist der Naturstand - zumindest verstehe ich das 
> so.
> 
> lg,
> Markus (ScubbX)
> 
> 
>> Am 11.07.19 um 09:10 schrieb Johann Haag:
>> Adress Sätze von Luzandro sind bekanntlich erschöpft. Es geht also nun darum 
>> mit dem Vorhandenem etwas sinnvolles anzufangen. Also bitte um Mitwirkung an 
>> einem Mustertext zur Aktivierung der Gemeinden . Ich bin nun drei Wochen in 
>> Urlaub, anschliessend möchte ich mit dieser Initiative beginnen.
>> 
>> Grüsse Johann
>> Von meinem iPhone gesendet
>> 
>>> Am 11.07.2019 um 08:26 schrieb Wolfgang Schreiter :
>>> 
>>> 
>>> 
>>> Am 11.07.2019 06:42 schrieb Johann Haag:
 Die Adress- Situation im Osten von Österreich stellt sich
 folgendermaßen dar. Aus verwaltungstechnischen Gründen, werden
 Adressen von Gemeinden, bereits bei der Bauland Widmung in Form von
 Zähl Adressen entlang der Straße vergeben. Anschließend kümmern
 sich Gemeinden und Städte offensichtlich nur noch wenig darum.
>>> Mag sein. Ist aber kein Pronblem, solange die von den Gemeinden vergebenen 
>>> Adressen nicht automatisch importiert, sondern von Mappern vor Ort 
>>> überprüft werden.
>>> 
 Ich
 werde also nun Gemeinden systematisch anschreiben, und darum bitten,
 dass dort wo es nun in unserem Projekt Adressen vollständig gibt.
 Diese von den Bauämtern gesichtet und bereinigt werden.
>>> Das ändert nichts daran, dass wir uns nicht blind auf die Daten der 
>>> Bauämter verlassen. Die Bauämter wissen, dass neu vergebene Adressen noch 
>>> bis zu einem gewissen Grad vorläufig sind. Die Unschärfe wird bewusst in 
>>> Kauf genommen und mit der Zeit korrigiert. Wo wir das zeitnaher/besser 
>>> können, liegt es an uns.
>>> 
 Ich bitte also die Community hier um offizielle Unterstützung einer
 solchen Initiative. Unser gemeinsames Ziel ist sicher OpenStreetMap
 besser zu machen. Daher meine Bitte um Vorschläge für einen
 Mustertext.
>>> Du ersuchst die Community um Unterstützung. Das setzt nicht nur Vertrauen 
>>> in Deinen Vorschlag, sondern auch zu Dir als Mapper voraus. Aktuell dreht 
>>> sich die Diskussion darum, Teile Deiner Imports rückgängig zu machen und 
>>> derartige (unabgestimmte, regelwidrige) Imports in Zukunft gar nicht mehr 
>>> zuzulassen (+1). Ich schlage vor, dass Du in Sachen Adressen zunächst 
>>> einmal nichts Neues unternimmst, sondern konstruktiv an der (manuellen) 
>>> Behebung der vorhandenen Schäden mitwirkst. Eine Nachdenkpause würde der 
>>> Sache gut tun.
>>> 
>>> Grüße
>>> Wolfgang
>>> 
>>> 
>>> ___
>>> Talk-at mailing list
>>> Talk-at@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-at
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-it] Problemi nella ricerca indirizzo con Maps.me

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 10:51, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> Non corretti nel senso che la parola "Chiuso", va scritta "chiuso" con
> la C minuscola, perchè non è un nome.


se il nome non fosse „Vicolo Chiuso“ non sarebbe da inserire nel tag “name”

È vero che “chiuso” è un aggettivo e non va scritto in maiuscolo, ma potrebbe 
essere diventato anche un nome (nel caso di una via per esempio).

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

Re: [Talk-us] Mapping rail trails

[Richard Fairhurst]

Kevin Kenny wrote:
> And route relations are important for sites like Waymarked Trails - 
> it totally ignores walking and cycling routes that are not indicated 
> with relations, which is why I wind up doing routes for even 
> relatively trivial stuff like
> https://www.openstreetmap.org/relation/4836600.(although 
> that certainly meets Richard's five-mile threshold).

Ok. I've just finished a pass through CONUS relationising pretty much all
the significant leisure trails I could find for which there weren't already
route relations. HDYC is telling me that "recently" I've added 334 bike
routes - I'm not sure what period that covers but it sounds about right.

By and large I've tagged them with network=lcn - there's certainly a case
for upgrading some to =rcn but I'll leave that to those with local
knowledge.

There's a bit of work still to do on smaller local trails that also form
part of a longer route - e.g. parts of the Bay Trail, or the East Coast
Greenway. It would be good to have a distinct C Canal Trail relation over
and above the USBRS 50 relation, for example.

cheers
Richard



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

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