Re: [OSM-talk] Q site update from Ops

[Tobias Wrede]

Also thanks from my side Mike.

As of today the help site seems to be working again but only a few days 
back it had been seeing the same problem again for several weeks. Who 
knows what is causing these periodic failures. So I'm looking forward to 
your monitoring and any possible short-term solution.


But even if this immediate JS/usability problem can be fixed there are 
still so many smaller annoyances that before long we should still look 
into migrating the site to a newer software.


cheers,
Tobias

Am 05.07.2020 um 10:16 schrieb Mateusz Konieczny via talk:

Thanks to entire Ops group for work on this and other things!


4 Jul 2020, 07:35 by m...@teczno.com:

Hi Everyone,

Since Tobias Wrede started this thread in May, the Ops group has
discussed the Help site during our regular meetings. We understand
the importance of the Q site and acknowledge that the software
running it is old and under-maintained.

In addition to the possibility of moving the site to a new
platform like the ones mentioned in this thread, we’ve also
verified that all past Q content can be archived [1] regardless
of future platform and talked about potential underlying causes of
the frontend script problems some users have experienced [2].
Currently, the Ops group has two initial conclusions:

1) We aren’t able to confirm the extent of the Javascript problems
described in this thread because we lack a front-end monitoring
that would provide this information. Our existing monitoring
extensively covers the underlying server, shenron [3], alongside
superficial uptime measurements [4].

2) The Q server is shared by Trac and SVN services which are
being deprecated over the next month [5]. Deprecating Trac and SVN
will allow us to better isolate and observe problems that Q is
experiencing, and perhaps solve them by removing these competing
services on one of OSM’s older pieces of hardware.

Over the next two months, I’ll be watching the thread [2] for
reports of new failures. If these continue past August when SVN
and Trac have been deprecated, we’ll add monitoring to better
understand their cause and determine what work may be needed to
fix or migrate OSM’s Q site.

-mike.

Links:
1. https://ops.pads.ccc.de/meeting-202006-A (archiving report
starts at line 173)
2.

https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work?

3.

https://munin.openstreetmap.org/openstreetmap.org/shenron.openstreetmap.org/index.html

4. https://uptime.openstreetmap.org
5.
https://lists.openstreetmap.org/pipermail/dev/2020-July/030958.html

Ops Meeting Minutes:
- https://ops.pads.ccc.de/meeting-202005-B (July 1)
- https://ops.pads.ccc.de/meeting-202006-A (June 4)
- https://ops.pads.ccc.de/meeting-202007-A (May 22)

On May 20, 2020, at 12:28 AM, Tobias Wrede
 wrote:

Hi,

we have several channels in OSM to facilitate discussions and
support. First touch point for new users is often
help.openstreetmap.org. Questions relating to mapping in
general, tagging, editors, development, OSM based applications
are asked there and get answered in most cases.

The site is based on OSQA, a software which has not been
maintained in some time. Some application errors have surface
in the past but had to be ignored since no fixes are coming
from OSQA any more. Until now we could live with that. They
were annoying but not critical. There are open tickets on OSM
github to move the help site to some other framework
(https://github.com/openstreetmap/operations/issues/149,
https://github.com/openstreetmap/operations/issues/377) but
there isn't exactly an abundance of volunteers to take care of
that.

Usability of help.openstreetmap.org has now seriously worsened
over the past few days with some js error popping up for
longer and longer times

(https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work).
Buttons to support formatting questions and answers are gone,
comments cannot be added and moderation functions (reporting,
converting questions to comments etc.) are not working anymore.

If this continuous we can shut down the site soon. Even if
this problem got resolved somehow it's only a matter of time
until a new problem arises. The site provides a low entry
hurdles place to ask questions that can be solved by simple
answers. I'd hate so see it gone.

I'm neither a programmer who could help out on the technical
side nor am I involved in OSM organization and politics to
have an idea on how this could be sorted out. Question around:
Can we find someone

Re: [OSM-talk] our Q site help.openstreetmap.org is dying

[Tobias Wrede]

Am 20.05.2020 um 21:32 schrieb Frederik Ramm:


We've taken great care to write our replies in a generic fashion where
possible, with the aim of collecting knowledge that others can profit
from (instead of asking the same question over and over again).

Not copying past answers, at least the last two years or so, would mean
we'd have to write all these answers again because the questions will
inevitably be asked.

I think it would be rather disrespectful to those who have invested a
lot of time into building a good body of knowledge in the old system to
say "let's throw away this content, main thing is we get a shiny new
system". And the alternative of having to keep the old system around in
a read-only fashion is not super attractive either.


Hi Frederik,

I'm myself among the more frequent contributors on the site. I'm not 
saying to throw everything away and would appreciate if one could still 
refer to the the old answers. But considering how long this issue has 
been hanging in the air without resolution I would favor a practical way 
over one that will let us wait another few years before something 
happens. In my view it should be possible to leave the old site in a 
read only state and start a new site from zero. We could still link to 
answers on the archived site. Of course I'd welcomed if there was a 
reasonably fast way of moving and migrating all the old Q


Tobias


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

Re: [OSM-talk] our Q site help.openstreetmap.org is dying

[Tobias Wrede]

Am 20.05.2020 um 16:04 schrieb Lester Caine:
... offers a hope that there is potential to pump existing material 
across?


I wouldn't worry too much about migrating past material to the new site. 
Of course that would be a plus but not doing so shouldn't stop us from 
migrating to something new and lasting soon.


Tobias


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

[OSM-talk] our Q site help.openstreetmap.org is dying

[Tobias Wrede]

Hi,

we have several channels in OSM to facilitate discussions and support. 
First touch point for new users is often help.openstreetmap.org. 
Questions relating to mapping in general, tagging, editors, development, 
OSM based applications are asked there and get answered in most cases.


The site is based on OSQA, a software which has not been maintained in 
some time. Some application errors have surface in the past but had to 
be ignored since no fixes are coming from OSQA any more. Until now we 
could live with that. They were annoying but not critical. There are 
open tickets on OSM github to move the help site to some other framework 
(https://github.com/openstreetmap/operations/issues/149, 
https://github.com/openstreetmap/operations/issues/377) but there isn't 
exactly an abundance of volunteers to take care of that.


Usability of help.openstreetmap.org has now seriously worsened over the 
past few days with some js error popping up for longer and longer times 
(https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work). 
Buttons to support formatting questions and answers are gone, comments 
cannot be added and moderation functions (reporting, converting 
questions to comments etc.) are not working anymore.


If this continuous we can shut down the site soon. Even if this problem 
got resolved somehow it's only a matter of time until a new problem 
arises. The site provides a low entry hurdles place to ask questions 
that can be solved by simple answers. I'd hate so see it gone.


I'm neither a programmer who could help out on the technical side nor am 
I involved in OSM organization and politics to have an idea on how this 
could be sorted out. Question around: Can we find someone to take care 
of the technical side? Can we involve any of the OSM organizations to 
find, maybe pay, someone? Does the community even find it worthwhile 
keeping the site?


cheers,

Tobias




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

Re: [Talk-de] Vorstellung deutsche Umap-Instanz

[Tobias Wrede]

Hallo Lars

bin erst jetzt auf diese Nachricht gestoßen. Interessant.

Gibt es Unterschiede zur Instanz auf umap.openstreetmap.fr? Ich habe 
gesehen, es stehen weniger Hintergründe zur Verfügung. Sonst noch was? 
Kann man Projekt von der französischen Instanz problemlos auf die 
deutsche portieren?


Ist von den Betreibern auch irgendjemand bei der Entwicklung involviert? 
Ich nutze uMap gerne, aber ein großes Problem ist, dass vom 
Entwicklerteam so gut wie gar nicht auf Probleme reagiert wird. Die 
Issue-Liste in Github wird länger und länger ohne irgendeinen 
Fortschritt zu sehen.


Anfragen zu uMap-Problemen landen häufig auf help.openstreetmap.org, 
aber da ist auch keiner von den Entwicklern oder Betreibern aus .fr zu 
finden. Antworten sind nur rudiementär möglich. Immer häufiger schlagen 
da Anfragen auf, dass Nutzer unangemeldet eine Karte erstellt haben und 
jetzt den geheimen Link zum Editieren nicht mehr finden. Für diese 
Nutzer ist es unmöglich, jemanden zu erreichen, der ihnen weiterhelfen 
kann. Gibt es in der neuen deutschen Instanz einen Ansprechpartner für 
solche Fälle? Auf der Seite wird, so weit ich das sehe, auch nur auf die 
gleiche Seite im Wiki verwiesen wie von der französichen Instanz.


beste Grüße
Tobias

Am 15.06.2019 um 11:46 schrieb lars lingner:

Hallo zusammen,

hiermit möchte ich auf die deutsche uMap-Instanz unter der URL
https://umap.openstreetmap.de aufmerksam machen.

Mit uMap können interaktive Karten auf einfache Art und Weise erstellt
werden. Die Software wird hauptsächlich in Frankreich [1] entwickelt und
ist Open Source.
Im OSM-Wiki [2] gibt es eine Anleitung, z.b. auch wie Daten direkt von
der Overpass-Api eingebunden werden können.

Die Kosten für das Hosting werden vom FOSSGIS e.V. [3] übernommen.

Probiert es aus und sagt es weiter.



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

Re: [OSM-talk] Bank of India (and other) Wikidata tags

[Tobias Wrede]

Am 17.04.2019 um 22:03 schrieb Mateusz Konieczny:

Among other popular wikipedia links

"wikipedia='de:Stolpersteine'",
"wikipedia='nl:Toeristisch Overstappunt'",

are also clearly invalid, though here brand:wikipedia would
be wrong and complete removal is probably necessary.


Martin already commented on de:Stolpersteine.

The adding of nl:Toeristisch Overstappunt has been questioned on the 
tagging list (starting with messages 
 and 
) but with no 
apparent outcome. I agree with you, in my opinion they are still dead wrong.


Tobias

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

Re: [Talk-de] Fehlender Lizenzvermerk bei Stern.de und Polizei Frankfurt

[Tobias Wrede]

Hallo Thomas,

Am 12.04.2019 um 07:24 schrieb Thomas Zimmermann:

Da die Presseverlage so große Urheberrechtsverfechter sind und die Polizei als
Vorbild dienen sollte, sollte man die beiden meiner Meinung nach auf diesen
Urheberrechtsverstoß hinweisen.


Immer zu. Da brauchst du hier nicht groß nachfragen, schick ihnen 
einfach eine E-Mail mit dem Sachverhalt. Habe ich schon öfters gemacht 
und jedes Mal Erfolg gehabt (bei der Europäischen Kommission hat es ein 
paar Monate gedauert zu den richtigen Verantwortlichen vozudringen, aber 
auch dort wurden auf der Webseite die Karten letztlich richtig 
ausgezeichnet).


Tobias


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

Re: [Talk-de] "Küss- und Tschüsszonen" / Elternhaltestellen

[Tobias Wrede]

Hallo,

ich kenn das an Bahnhöfen als Kiss & Ride. Kurze Suche auf OSM zeigt, 
dass das sehr oft einfach als name=kiss and ride an Straßen, parking 
aisles, localities etc getaggt ist. K: Kraut und Rüben könnte man sagen.


Tobi


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

Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool

[Tobias Wrede]

Hallo Stefan,

Am 19.02.2019 um 09:24 schrieb Stefan Keller:

Feedback willkommen - hier oder als Issue im Repository!


Läuft weitgehend gut.

Hier ein paar Fälle, die das Tool nicht erkannt hat:

11:30 bis 22 Uhr, sonntags bis 21 Uhr

Tool 1: 11:30-22:00
Tool 2: 11:30-22:00,Su-

Beim diesem zugegebenermaßen nicht eindeutigen Fall kommt seltsames raus:

11 bis 1 Uhr | Küche 11:30 bis 22 Uhr, sonntags bis 21 Uhr

Tool 1: nichts
Tool 2: 11-01:00,11:30-22:00,Su- (zusätzlich zu oben fehlen bei der 11 
vorne die Minuten)


Tool 2 macht es richtig, Tool 1 vergisst den Donnerstag:

geöffnet täglich von 10:00 bis 01:00 Uhr
Donnerstags Ruhetag

Tool 1: Mo-Su 10:00-01:00
Tool 2: Mo-Su 10:00-01:00; Th off

Und damit kommen beide Tools komplett durcheinander:

Montag Ruhetag
Dienstag - Samstag
17:00 - Open End
Sonn. und Feiertags
12:00 - 14:30 Uhr &
17:00 - Open End


beste Grüße

Tobias


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

Re: [Talk-de] Smoothness nur für Wege oder auch für Straßen

[Tobias Wrede]

Am 12.10.2018 um 07:39 schrieb Volker Schmidt:

Die Were des "smoothness" tag sind auf Autos bezogen, nicht auf Fahrräder,
wenn du im wiki nachschaust. Sind dann aber von der user community auch für
Radfahrer verwendet worden.

In welchem Wiki schaust du denn? Im OSM-Wiki (und auch schon im 
Proposal)  beziehen sich die wenigsten Beispiele auf Autos. In den 
beiden höchsten Klassen sind Autos noch nicht mal erwähnt.


Tobias


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

Re: [Talk-de] Wiki-Eintrag falsch?

[Tobias Wrede]

Am 05.10.2018 um 12:43 schrieb sepp1...@posteo.de:


In D werden Brückenhöhen i.d.R. durch Zeichen 265 ab einer 
Durchfahrtshöhe von 4,20m gekennzeichnet, im Einzelfall auch ab einer 
höheren möglichen Durchfahrtshöhe, je nach (regelmäßiger) 
Straßennutzung durch Sondertransporte. Auch auf Autobahnen werden 
Brücken oft mit schräg zum darunter verlaufenden Straßennieveau sogar 
für einzelne Fahrspuren mit unterschiedlichen Höhenangaben unterhalb 
der 4,50m-Grenze kenntlich gemacht.


Das müßte geändert werden, oder habe ich da etwas falsch interpretiert?


Da müsste auf jeden Fall etwas geändert werden. Ist das mit Google 
Translate übersetzt? Ich habe die Feldinhalte drei mal gelesen und dann 
in die englische Version geschaut, um überhaupt zu verstehen, was die 
Tabelle eigentlich sagen will.


Falls es ein 4,20m Default in DE gibt, kann man das gerne auch 
korrigieren, dann aber klar mit dieser DE-Einschränkung. Die Seite gilt 
ja prinzipiell global.


Tobi


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

Re: [Talk-de] Abknickende Vorfahrt

[Tobias Wrede]

Am 02.10.2018 um 16:09 schrieb Florian Lohoff:

On Tue, Oct 02, 2018 at 12:29:51PM +0200, Tobias Wrede wrote:

D.h. evtl. Geschwindigkeitsbeschränkungen müssen nach der Kurve neu gesetzt
werden?

Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die Frage,
ob Strecken-Beschränkungen weiter gelten, ist umstritten.

IIRC ist das Gerichtlich sauber geklärt.

Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben ist.

[...]
https://www.burhoff.de/rspr/texte/ab_00028.htm

[...]

"Es ist einhellige Meinung in Literatur und Rechtsprechung, dass eine
durch Zeichen 274 angeordnete Geschwindigkeitsbeschränkung als sog.
Streckenverbot erst an einen gemäß § 41 Abs. 2 Nr. 7 StVO aufgestellten
Zeichen 278 endet (vgl. Hentschel, Straßenverkehrsrecht, 36. Aufl., § 3
StVO Rdnr. 46 m.w.Nachw.; Beschluss des Senats vom 8. Juli 1996, abgedr.
in NZV 1996, 247). Zwar verlangt der Sichtbarkeitsgrundsatz die
Wiederholung aller Streckenvorschriftszeichen hinter jeder Kreuzung oder
Einmündung auf der Straßenseite, für die das Gebot oder Verbot besteht;
dies gilt jedoch nur für den Einbiegeverkehr."

Das ist unstrittig. Strittig ist, was die "Strecke" ist. Bei einer 
Kreuzung ohne abknickende Vorfahrt ist klar, dass die Strecke geradeaus 
weiterführt. Bei einer abknickenden Vorfahrt scheiden sich die Geister. 
Manche sagen, die Strecke endet dort (wie z. B. bei Einmündung auf eine 
T-Kreuzung), manche sagen, die Strecke führt geradeaus weiter und manche 
sagen schließlich, die Strecke folgt der Vorfahrtstraße. Dazu gib es so 
weit ich weiß keine Rechtssprechung.


Tobi


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

Re: [Talk-de] Abknickende Vorfahrt

[Tobias Wrede]

Am 02.10.2018 um 12:52 schrieb Martin Koppenhoefer:


sent from a phone


On 2. Oct 2018, at 12:29, Tobias Wrede  wrote:

Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die 
Frage, ob Strecken-Beschränkungen weiter gelten, ist umstritten.


unumstritten ist eigentlich nur, dass man blinken muss, oder?


Vor allem muss man auch querende Fußgänger durchlassen. Ein Aspekt, der 
vielen Autofahrern leider nicht bewusst ist.


Gruß

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

Re: [Talk-de] Abknickende Vorfahrt

[Tobias Wrede]

Hi Martin,


Am 02.10.2018 um 12:11 schrieb Martin Koppenhoefer:



Und auch für den rechtlichen Vorgang ist es - in Deutschland - immer
noch ein Abbiegen. Mit all den Konsequenzen, die ein Abbiegen hat


ein wenig sollte ich meine Aussage vielleicht relativieren. Die Regeln 
dazu sind nämlich nicht ganz eindeutig und es kommen teilweise auch  
unterschiedliche §§ in der StVO zur Anwendung, die das gleiche fordern.





D.h. evtl. Geschwindigkeitsbeschränkungen müssen nach der Kurve neu gesetzt
werden?

Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die 
Frage, ob Strecken-Beschränkungen weiter gelten, ist umstritten.


Gruß,

Tobi


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

Re: [Talk-de] Abknickende Vorfahrt

[Tobias Wrede]

Hallo in die Runde,

Am 01.10.2018 um 15:49 schrieb Florian Lohoff:

Hi Andreas,

On Fri, Sep 28, 2018 at 09:06:07PM +0200, Andreas Schmidt wrote:

Wenn man abbiegt, biegt man ab.
Ob die Vorfahrtsstraße mit abbiegt oder geradeaus geht, ist für die
Frage des Abbiegens irrelevant.

Für den physischen Vorgang des abbiegens und Deutschland gebe ich dir
recht.


Und auch für den rechtlichen Vorgang ist es - in Deutschland - immer 
noch ein Abbiegen. Mit all den Konsequenzen, die ein Abbiegen hat, mit 
der Ausnahme, dass entgegenkommender Fahrzeugverkehr ggf. warten muss. 
Auf Fußgänger trifft das nicht zu.



Festeinbau Mercedes - Keine Ansage - Erwartung das der
abknickenden Vorfahrt gefolgt wird.

Mercedes hat eh eingebaute Vorfahrt, oder wie war das? ;-) Hoffe, die 
Fahrer verlassen sich nicht leichtsinnig auf die Ansagen.


Tobi


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

Re: [Talk-de] Zerstörtes Gebäude (demolished) einzeichen (Schild verweist auf Standort)

[Tobias Wrede]

Hallo,

ganz korrekt ist der Eintrag in meinen Augen nicht. Generell würde ich 
tendieren ihn bestehenzulassen. Allerdings passen die Tags in meinen 
Augen nicht zusammen.


razed:man_made=watermill -> Eine Wassermühle, die "razed" ist.
historic=watermill -> undokumentiertes Tag, das aber das gleiche aussagt 
wie man_made=watermill, diesmal aber ohne lifecycle prefix.
demolished=yes -> auch kein dokumentiertes Tag, oder? Sollte wie oben 
razed: als Prefix demolished: genutzt werden. Steht jetzt im Widerspruch 
zu razed:.


Aus den drei Tags sollte meiner Meinung nach genau eins werden:
razed:man_made=watermill (oder demolished:man_made=watermill, der 
Unterschied ist nicht wirklich scharf und nachvollziehbar)
Mann könnte sogar auch noch ein razed:building=yes ergänzen, wenn es 
sich hier nicht um eine offene Mühle gehandelt hat.


Wenn man den Standpunkt vertritt, ein nicht mehr vorhandenes und 
inzwischen überbautes Objekt sollte gar nicht in der Karte auftauchen, 
kann man das ganze sicherlich auch in place=locality ändern.


Tobias

Am 17.06.2018 um 17:19 schrieb Manuel Reimer:

Hallo,

da bei uns recht ordentlich erfasst ist, habe ich direkt am Wohnort 
schon einige Zeit keine Änderungen mehr an der Karte gemacht.


Vor wenigen Tagen habe ich aber mal geschaut was für Kartenfehler 
gemeldet sind. Dabei bin ich auf folgenden gestoßen:


https://www.openstreetmap.org/note/1197712#map=17/49.97016/9.64038=N 



Erfasst hatte ich den mit/für den lokalen Heimat- und 
Geschichtsverein. Die Mühle ist in zahlreichen Flyern erwähnt und im 
"lokalen Sprachgebrauch" durchaus noch üblich.


https://www.openstreetmap.org/node/1028449854#map=17/49.9705928/9.6378074layers=N 



Ich war bisher der Meinung das alles korrekt eingetragen zu haben. Das 
Abrissdatum ist drin, es ist explizit darauf hingewiesen, dass das 
Gebäude abgerissen wurde.


Im Gegensatz zu so manchem erfassten "abgerissenen" Gebäude ist in 
gewissem Maß sogar das Gebot "nur mappen was vor Ort nachvollzogen 
werden kann" gewahrt. Eine Tafel vom Spessartbund (hier verläuft ein 
Kulturweg, der auch mehrfach auf die Mühlen hinweist) verweist auf den 
Standort. Kann also für jeden nachvollzogen werden auch ohne 
"Ortskundige" zu fragen.


Hintergrund für das Anlegen des Knotens war, dass ich gerne einen 
Eintrag dafür hier haben wollte:


http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=17=49.96999=9.63967=HaHbHcSaHe 



Steht da auch korrekt als "former watermill location".

Weiterhin nutze ich den Knoten auf der Karte des Heimat- und 
Geschichtsvereins um Infos zum (ehemaligen) Gebäude auf die Karte zu 
packen:


http://karte.hgv-steinfeld.de/

Wie ist die Meinung hier dazu. Wenn es komplett falsch ist, sowas zu 
mappen, dann kann ich das mit meiner Karte auch anders lösen.


Ich selber tendiere aktuell dazu den Fehler mit einem Hinweis auf die 
Tafel, die auf den Standort des ursprünglichen Gebäudes hinweist, zu 
schließen.


Gruß

Manuel


___
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

Re: [Talk-se] ID översättningar

[Tobias Wrede]

I Tyskland hade vi samma diskussionen. "path" översettades till "Pfad" 
vilken har samma meningen som svensk "stig" ("något mindre is skogen") 
men inte något some är cycle- eller gångväg i stan. Men hw=path infördes 
precis att ersätta hw=footway och hw=cycleway  i obestämda situationer 
(https://wiki.openstreetmap.org/wiki/Approved_features/Path).


 Tysk begreppet för path i ID är nu "Mehrzweckweg" (flerfunktionsväg?) 
vilket inte alls är något meningsfull men är lite bättre som missledande 
"Pfad".


Jag tror hw=path är etablerad nu för både den mindre stigen in skogen 
och den vanlig gångväg i stan. Surface, width, smoothness etc. användas 
för att bättre bestämmer vilken sorts sig/väg det är egentligen.


/Tobi

Am 11.05.2017 um 18:49 schrieb M Branting:


Det är nog ingen bra idé att tagga naturstigar på samma sätt som breda 
gc-banor. Att skyltade cykelbanor för taggas cyclelway är väl 
självklart. Mindre uppenbart är det med de vanliga gång och 
cykelvägarna (gc-banorna). Om man betraktar dem som cykelbanor där 
även gångtrafik är tillåten så kan man tagga dem som cyclelway med 
foot=yes


Jag håller alltså med om att path (stig) bör reserveras för 
(natur)stigar . Här är istället frågan om avgränsningen mot ”bruksväg” 
(track) som av någon obegriplig anledning översatts till ”ej 
underhållen bruksväg”.


Skickades från E-post  
för Windows 10


*Från: *Mattias Dalkvist 
*Skickat: *den 11 maj 2017 18:14
*Till: *OpenStreetMap Sverige mailinglista 


*Ämne: *[Talk-se] ID översättningar

Hej

I ID så är highway=path översatt med stig vilket de många förknippar 
med något mindre i skogen, inte alls lika generellt som det Engelska 
uttrycket.


Ett av de rekommenderade sätten att tagga gång- och cykelbanor är ju 
highway=path med  foot=designated och bicycle=designated och jag har 
sätt flera nybörjare som ändrar dem till footway. Har också sätt några 
som satt highway=footway och highway=cycleway


Någon som kan komma på något bättre än Stig?

Det ända jag kommer på är något i stil med "Stig, gång- & cykelväg" 
vilket inte är så bra ;)


--

Dalkvist



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



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

Re: [Talk-de] JOSM: Weg an anderem Weg beginnen *ohne* die zwei zu verschmelzen!

[Tobias Wrede]

Hallo Manuel,

Am 16.11.2016 um 20:39 schrieb Martin Koppenhoefer:
Il giorno 16 nov 2016, alle ore 18:32, Manuel Reimer 
 ha scritto:

Das mit "Alt" habe ich durch Probieren auch schon rausgefunden. Allerdings wird 
der Weg so auch nicht verbunden.

eigentlich wird der schon verbunden, wie sind deine einzelnen Schritte denn?

Bei Strg werden die ways nicht verbunden. Hast du evtl AltGr und nicht 
Alt benutzt?


Tobias

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

Re: [Talk-de] JOSM: Weg an anderem Weg beginnen *ohne* die zwei zu verschmelzen!

[Tobias Wrede]

Halo Manuel,

Am 11.11.2016 um 11:30 schrieb Manuel Reimer:
Ich hätte gerne das alte Verhalten wieder! Wie starte ich einen Weg 
von einem bestehenden ohne das mir JOSM die zwei verschmelzt? 

Unter Windows: Alt drücken beim Setzen des nächsten Nodes.

Tobias

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

Re: [Talk-de] Handball?

[Tobias Wrede]

Am 01.10.2016 um 18:51 schrieb Sven Geggus:

Tobias Wrede <l...@tobias-wrede.de> wrote:


In den USA versteht man unter Handball eine Art Squash ohne Schläger
(https://de.wikipedia.org/wiki/American_Handball).

Das kann dann ja per Definition nicht im Freien gespielt werden oder?

Worauf ich raus will. Man könnte die Kombination mit building und pitch
beachten.
Ui. Jetzt sind es schon drei Wochen her und die Diskussion schon 
eingeschlafen, aber trotzdem noch kurz eine Antwort hier drauf:


Nein, amerikanisches Handball wird auch draußen gespielt. Tatsächlich 
stehen da in Parks und Sportanlagen öfters mal Betonwände für genau den 
Zweck rum.


Gruß
Tobias

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

Re: [Talk-de] Handball?

[Tobias Wrede]

In den USA versteht man unter Handball eine Art Squash ohne Schläger 
(https://de.wikipedia.org/wiki/American_Handball).


team_handball nach handball umzutaggen wäre wohl unproblematisch. Es ist 
aber nicht auszuschließen, dass unter den "handball" getaggten pitches 
nicht auch solche für American Handball zu finden sind.


Gruß
Tobias

Am 27.09.2016 um 10:50 schrieb Martin Koppenhoefer:


sent from a phone


Il giorno 27 set 2016, alle ore 09:41, Sven Geggus 
 ha scritto:

Hm, sollten wir über einen mechanischen edit diskutieren, der
sport=team_handball in sport=handball ändert?


gibt es Handball auch als Einzelsportart, oder ist das immer ein 
Mannschaftssport? ;-)

+1 von mir für den mechanischen Edit zur Normalisierung. handball ist lt Wiki die 
britische und die olympische Schreibweise, von daher wäre es m.E. durchaus noch 
vertretbar, den etwas weniger genutzten Wert "gewinnen" zu lassen


Gruß,
Martin
___
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

Re: [Talk-de] Mobile Verkaufsstände

[Tobias Wrede]

Hallo,

Am 13.07.2016 um 11:46 schrieb Martin Koppenhoefer:

Am 13. Juli 2016 um 11:27 schrieb Carl von Einem :


Und als "tag, der signalisiert, dass das Teil da in 95% der Zeit in der
man vorbeikommt überhaupt nicht anzutreffen ist", würde ich opening_hours
vorschlagen.

Ich würde für einen
anderen tag plädieren, so dass man als Datenkonsument einfacher erkennen
kann, ob man da überhaupt üblicherweise was antrifft, oder ob das Zelt nur
während des Oktoberfests (oder der Stand nur während der Marktzeiten oder
der Stand am Straßenrand nur in der Saison) dort ist.

Generell gehört sowas meiner Meinung nach in die Datenbank rein. Ich 
habe hier in Leverkusen auch Standorte von Schadstoffmobilen (1x im 
Monat) und Grünschnittcontainern (1x die Woche) getaggt. Beide haben 
regelmäßige, veröffentlichte Zeiten. Die Hähnchen-, Fisch-, Blumen-, 
etc.-Wagen mögen keine so verbindlichen, veröffentlichten Zeiten haben, 
sind meiner Erfahrung nach aber auch über Jahre hinweg regelmäßig zur 
gleichen Zeit anzutreffen. Die möchte ich also auch finde können.


Ich finde die Idee aber gut, den mobilen Charakter deutlich zu machen. 
Das sollte meiner Meinung nach aber keine anderer Tag sein (dann 
bräuchten wir jeweils einen anderen Shop-, Recycling-, Fast-Food-, 
etc.-Tag), aber ruhig ein zusätzlicher. Amenity:mobile=yes oder 
ähnliches. Keine Ahnung, wie man so was korrekt in en-gb ausdrücken würde.


Gruß
Tobias

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