Re: [OSM-talk] OSRM Update

2023-08-27 Thread michael spreng (datendelphin)
It normally takes about 5 days for a full update cycle (all profiles). 
It was just stuck until last Wednesday.


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


Re: [OSRM-talk] Routing does not working in Latin America

2020-11-18 Thread michael spreng
Hi Carlos

Thank you for the report. It looks like the copy this morning was
incomplete. It should be fixed soon (copying 90GB takes some time)

Michael

On 18.11.20 15:45, Carlos García wrote:
> Dear all.
> 
> Since the last update (18/11/2020 02:00) of the routes for Latin
> America, it is not posible to create any route.
> 
> In the link below, all of the ways appear gray:
> https://routing.openstreetmap.de/debug/car.html#15/4.5980/-74.0976
> OpenStreetMap Routing with Open Source Routing Machine
> 
> 10-20. 20-30. 30-40
> routing.openstreetmap.de
> 
> 
> Could you, please, check what is going on?
> 
> _/Carlos Enrique García Bernal/ _
> 
>  
> 
> ___
> 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


Re: [OSRM-talk] OSRM does not use date restrictions in conditional access?

2020-10-13 Thread michael spreng
Hi Maarten

It currently does not. There is an update cycle of about 4 days. I think
such date ranges would make sense to use at the time of generation
(however day time ranges would still be ignored). But that is not yet
implemented as far as I know. It could be implemented in the lua
profile, so probably no deeper knowledge of osrm is necessary to
implement this.

Michael

On 13.10.20 08:20, Maarten Deen wrote:
> Conditional access rules for time and date restrictions follow the same
> syntax as opening hours rules, see
> https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Condition
> 
> I have way https://www.openstreetmap.org/way/96440420 with
> highway=cycleway+access:conditional=no @ (2019 Okt 07-2021 Apr 29)
> This cycleway is inaccessible from october 7th 2019 until april 29th
> 2021, so currently it should not be routed over.
> But OSRM cycle routing does use this road:
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=51.9792%2C4.2676%3B51.9835%2C4.2554#map=17/51.98019/4.26387
> 
> 
> Does OSRM not use conditional restrictions?
> 
> Regards,
> Maarten
> 
> ___
> 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


Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

2020-08-25 Thread michael spreng
On 25.08.20 07:41, Rolf Eike Beer wrote:
> Am Samstag, 22. August 2020, 10:42:00 CEST schrieb Rolf Eike Beer:
> 
> Und wenn man jetzt noch das Formular hinter eine OSM-OAuth-Anmeldung steckt, 
> dann kennt man sogar schon den Benutzernamen _und_ man kann sich die 
> Nachfrage 
> beim Benutzer sparen: win-win!
> 

Ja wir arbeiten auf dieser Scheine, dass irgendwann der Nutzername via
OAuth kommt. Tatsächlich besteht der Wunsch nach OAuth Integration von
Seite der MWG schon seit dem alten fee-waiver. Und ziemlich sicher
bekommen wir auch das Budget, das entwickeln zu lassen. Leider ist es
trotzdem für uns ein erheblicher Aufwand und darum geht das so langsam
vorwärts. Wenn wir auf die OAuth Erweiterung gewartet hätten, wäre wohl
nächstes Jahr noch nichts umgesetzt. Darum beissen wir in den sauren
Apfel und haben wesentlich mehr Aufwand pro Antrag, aber dafür ist die
active contributor membership verfügbar.

Wie immer, wir haben weitaus mehr Arbeit wie Mithilfe, alle sind
willkommen mitzuarbeiten.
https://wiki.osmfoundation.org/wiki/Membership_Working_Group

Grüsse
Michael
membership working group

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


Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

2020-08-22 Thread michael spreng
Hallo Eike

On 22.08.20 10:42, Rolf Eike Beer wrote:

> Ganz toll wäre es, wenn man die Eingabefelder durch URL-Parameter vorbelegen 
> könnte.
> 

Kannst du das etwas ausführen, was da der usecase wäre?

Grüsse
Michael

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


Re: [OSRM-talk] OSRM Decentralized

2020-08-02 Thread michael spreng
Hi Nikhil

Thank you for realizing this, nice demo.

I think an automatic narrowing down of available back ends after
entering start and end coordinates would be an important feature (and
consequently an extension is needed to the configuration file to include
polygons for the available routing area)

Cheers,
Michael

On 02.08.20 09:46, Nikhil VJ wrote:
> Hi Folks,
> 
> Here are easy docker recipes for deploying your own OSRM instance for
> any base area. And a live demo page where OSRM for different areas can
> be brought together.
> 
> https://osrm-decentralized.github.io/
> 
> 
> --
> Cheers,
> Nikhil VJ
> https://nikhilvj.co.in
> 
> ___
> 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


[OSM-talk] proposal OSMF active contributor membership

2020-04-01 Thread michael spreng
Hi

Last December at the AGM a proposal for membership in the OSMF based
solely on sizeable contribution was accepted with a very good result
(91%):
https://wiki.osmfoundation.org/wiki/Annual_General_Meetings/2019/Suggested_AoA_Changes_revised#Vote_8:_Fee_waiver_for_mappers.2Fcontributors
In January, the membership working group discussed the implementation:
https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/MWG_2020-01-19
Sorry for the long silence since ; I would now like to open the
discussion and ask for your feedback and comments on the implementation
of the new active contributor membership

As described in the rationale for the vote, this is no charity. We want
active contributors to be member of the OSMF and be able to vote for the
benefit of the project. The membership fee should not be a barrier.

Our proposal is to automatically grant memberships to mappers who
request it and who have contributed at least 42 calendar days in the
last year (365 days).

Mapping days is not perfect, but we need a benchmark that is objective,
easy to verify, and simple for us to measure and implement.

Why 42 days? If we measure contributions in mapping days by OSMF members
who map (83%), roughly half of them map more than 42 days per year. We
would expect a “slightly exceptional” contribution in terms of mapping days.

We also discussed abuse. You could of course make tiny contributions
like wiggling a single node on 60 days, and maybe go undetected and get
your membership. But that would be fraud, and the membership could be
revoked if MWG finds out that the contributions are not meaningful.

Not everyone contributes by mapping, and some of the most familiar names
in our members list barely map. Some are very involved, for example, in
organizing conferences. Those other forms of contribution should be
recognised as well, and the board would take circular decisions on these
applications.

Please share your thoughts.

Best regards
Michael
Membership working group


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


Re: [OSM-talk] MWG needs some customizations in CiviCRM

2020-02-05 Thread michael spreng
On 26/01/2020 15:28, Martin Koppenhoefer wrote:
> what about multiple OpenStreetMap userIDs controlled by the same user? Our 
> current guidelines actively encourage the creation of multiple logins/users.
>
> Cheers Martin 

Hi Martin

That is a good point that hasn't occurred to me yet. However I have
difficulties imagining a use case. We recommend multiple accounts mostly
in two cases: privacy and for separating automated edits. If you do it
for privacy, then better not link them together via the membership
registry. The registry is not public, but can be inspected by members. I
would rather not make the software more complicated for a rare case
which can be handled manually by the MWG. But that is just my opinion.
We will keep it in mind in any case.

Just to make it clear: even with this planned automation, you can always
submit your case for manual review.

Michael


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


[OSM-talk] MWG needs some customizations in CiviCRM

2020-01-26 Thread michael spreng
Hi

The MWG needs some customisation in CiviCRM to improve user friendliness
of the membership. Foremost we would like to authenticate members
against openstreetmap with OAuth. Currently we verify OSM user names by
sending a message through OSM. There are a few other customizations
which we talked about. We wrote a short requirements document. But this
is not set in stone. we have improvements in mind, how they are
technically solved is secondary. They should be solved in an efficient
and future oriented way (there are regular updates to WordPress and
CiviCRM which we need to apply).

If anybody from the community is willing to help us in a short time
frame of about 3 months, we would of course welcome this. Otherwise we
would move to hire some professional for those tasks, probably Jon who
already helped us with the renewal reminder issue.

best regards
Michael
Membership Working Group




OAuth integration for CiviCRM
=

Wish list
* Let users link their OSM account through OAuth. Record user iD in Database
  - for fee-waiver type memberships compulsory
- ideally call an external url to verify if the new member fulfills
the requirement and create a membership automatically
  - for paid memberships as an option
  - for event registration as an option
  - use osm-id as deduplication id
* Automatic mailing list subscription from membership form checkbox
* Multilingual support
  - We might need to switch to Drupal to get that?

Rationale: OSM user account needs to be verified for fee-waiver memberships
Because we require a minimum contribution, we need to reliably know the
OSM account of the applicant. We then check the OSM account for this
minimum contribution criteria.

Requirements OAuth
==
OAuth for OpenStreetMap is used to authenticate editors to make changes
to the map on behalf of the identified contributor. However, it is also
often used to simply identify an OpenStreetMap contributor, by only
requiring to "read preferences" where the user id can be read.
We would like to use OAuth for that purpose, to give contributors the
possibility to identify themselves automatically.
OAuth, by design, needs to open the openstreetmap.org website. This can
be in a pop up or by navigation to the respective page and setting the
redirect after authentication to return to join.osmfoundation.org
OAuth can be implemented to be done before filling out the form, or for
example by a button press on the form. The form should reflect the
state, if the user authenticated with OAuth already or not.

The following forms need OAuth authentication:
- membership form http://join.osmfoundation.org/normal-membership/ and
http://join.osmfoundation.org/associate-membership/
Maybe also the "contact forms" form, if we can't handle fee-waiver
members with the membership form:
- fee-waiver forms
https://join.osmfoundation.org/application-form-for-lack-of-suitable-money-transfer/
and
https://join.osmfoundation.org/application-form-for-financial-hardship/
They are both based on the "contact forms" WordPress plug in. If
convenient, we can use any other type of form, it is just important that
we can generate a ticket for each submission in our ticketing system
otrs, which is usually done by sending a mail to m...@otrs.osmfoundation.org

A custom field should save the OpenStreetMap user id (number) which is
final. The OSM user name can be changed at any time.

fee-waiver: Requirements for active contributor member sign up
==

We have members who do not pay a membership fee. They are required to
meet a certain contribution level to become/stay a member. Currently,
they fill out just a form (contact forms, see above). But ideally we
would like to have a form like the paying membership form, but instead
of payment, their oauth authenticated osm user id is used to look up
their contributions, if they meet our criteria. That look up would be a
simple http document with the osm user id as parameter in the URL.
People not meeting the requirement (but still authenticated by oauth)
should get an entry in civicrm with a membership pending or similar.
Because they can still have contributed significantly and the board will
judge their case.
There needs to be a free text field for members to describe their
contribution.

deduplication on OSM user id


We would like to avoid having duplicate contacts with the same osm user
id. Ideally the membership sign up process will automatically recognize
the already used osm user id and reuse that contact entry, like it is
done for email addresses.

subscription to a mailing list
==

We use a mailman mailing list for communication amongst members. Only
members can subscribe. Now we would like to get a checkbox onto the
membership form "subscribe to osmf-talk mailng list" and when chat box
is checked, a http request could subscribe that mail address.



Re: [OSRM-talk] OSRM Demoserver - call for hosting volunteers

2020-01-24 Thread michael spreng
Hi

I'm one of the operators running routing.openstreetmap.de which is
sponsored by Fossgis. Even though that service is aimed at OpenStreetMap
contributors and to showcase OSM Data, it means that there would still
be a publicly accessible instance.
Though we have currently a much smaller load than 10k/min but we offer
routing profiles for foot and bike as well

Michael


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


Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung

2019-10-16 Thread michael spreng
Hallo Roland

On 15/10/2019 13:06, Roland Olbricht wrote:
> Hallo Michael,
>
> Kurzfassung: Ich würde mir
> 120 km/h für maxspeed=signals  und
>  80 km/h für highway=motorway_link
> wünschen.
>
das tönt vernünftig. Ich muss mal anschauen, ob ich eine Obergrenze für
den motorway_link in das Profil rein bekomme. Ich hoffe einfach, es
mappt niemand Kilometer lange motorway_link

Grüsse
Michael

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


Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung

2019-10-13 Thread michael spreng
Ich interpretiere das leicht anders. routing.openstreetmap.de braucht
einen anderen Regelsatz:
https://github.com/fossgis-routing-server/cbf-routing-profiles

Die auf/abfahrt ist mit maxspeed=none gemappt, welches in 140kmh
übersetzt wird.
maxspeed=signals hingegen ist dem Profil unbekannt, und es wird der
weltweite default für motorway von 90kmh angenommen.

Wäre es nicht sinnvoll, die auf/abfahrten mit demselben maxspeed zu
tagen wie die parallele Autobahn?

Was für eine Geschwindigkeit sollte vom routing bei signals angenommen
werden?

Grüsse
Michael

On 12/10/2019 16:35, Holger Bruch wrote:
> Im Gegensatz zu den anderen Auffahrten/Abfahrten sind die Parallelfahrbahn 
> und zwei Rampen mit  source:maxspeed=DE:motorway getaggt: 
> http://overpass-turbo.eu/s/N3w 
> 
> Dies wird durch OSRM interpretiert: 
> https://github.com/Project-OSRM/osrm-backend/pull/5217/commits/801d0ebe4d12f4eaa139c46066fa46e8f1764683
> 
> Viele Grüße,
> Holger
> 
> 
>> Am 12.10.2019 um 08:19 schrieb Harald Hartmann 
>> :
>>
>> Interessant ist auch der NordWestliche "Kreisel" mit bis zu 119km/h :-D
>>
>> Am 12.10.19 um 08:16 schrieb Harald Hartmann:
>>> siehe auch diese Debug-Ansicht:
>>> https://routing.openstreetmap.de/debug/car.html#16.73/51.53445/7.89292
>>>
>>> Die Nebenspur mit 112km/h gewertet, die Hauptspur nur mit 90km/h
>>>
>>> ___
>>> 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
>>
> 
> ___
> 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-transit] Long bus routes

2019-08-07 Thread michael spreng
Hi

On 06/08/2019 15:06, Jarek Piórkowski wrote:
> 
> The currently mapped Flixbus routes are just guessing as well - buses
> can deviate as long as they make the scheduled stops.
> I think so as well, judging from newspaper articles about bus drivers
taking wrong routes (not leading to the station)

But I'd like to get back to the sustainability argument. It is difficult
editing data with routes and not breaking them. We should not require
experts to edit roads. We should keep the relations manageable. It pains
me to see new mappers attacked by experienced ones, because their
favourite bus route broke. For me edits on the roads have priority and
we should not require knowledge of the route part of PT relations.

Anyway, I'm in favour of not adding routes to those long range bus
relations. If someone maps them, they should not complain if they break.
I don't see The use case.

Michael

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


Re: [Talk-it] edit war, tunnel del Gran San Bernardovia andrea enzo lattmann.

2019-03-12 Thread michael spreng
Se guardo una foto dell'ingresso del tunnel, vedo la segnaletica di un
"highway=trunk". Vedi
https://images.mapillary.com/JBXKcU9j-nqdb3HX000syg/thumb-2048.jpg e
https://wiki.openstreetmap.org/wiki/Switzerland/Map_Features
Purtroppo non parlo italiano, questa è una traduzione automatica.

Michael

On 12/03/2019 17:06, Ilario Valdelli wrote:
> Si. Quest'ultimo tratto e' corretto e puo' essere autostrada perche' sul
> lato Italiano si paga pedaggio per la galleria.  
> 
> Invece le gallerie in Svizzera non possono essere a pedaggio.
> 
> On Tue, 12 Mar 2019, 17:01 Andrea Musuruane,  > wrote:
> 
> Io di incroci a raso non ne vedo:
> https://www.openstreetmap.org/relation/2753691
> 
> Ciao,
> 
> Andrea
> 
> 
> On Tue, Mar 12, 2019 at 4:51 PM Ilario Valdelli  > wrote:
> 
> Direi solo I cartelli perchè,  posso assicurare, che a 130 non
> si puo' andare.
> 
> Quando dico che attraversa i paesi intendo incroci e semafori. 
> 
> On Tue, 12 Mar 2019, 16:48 Andrea Musuruane,  > wrote:
> 
> Il problema non è se assomiglia o meno. E' se ci sono i
> cartelli verdi o meno. E i cartelli ci sono. Quindi è
> un'autostrada, con tutto quello che ne consegue (limiti di
> accesso, ecc)
> 
> Ciao,
> 
> Andrea
> 
> 
> On Tue, Mar 12, 2019 at 4:29 PM Ilario Valdelli
> mailto:valde...@gmail.com>> wrote:
> 
> Forse solo il pezzo di tunnel e probabilmente per
> giustificare il pedaggio, ma la strada non sembra essere
> niente che assomiglia ad un'autostrada.
> 
> On Tue, 12 Mar 2019, 16:15 Andrea Musuruane,
> mailto:musur...@gmail.com>> wrote:
> 
> Il traforo è segnalato come autostrada, con tanto di
> cartelli verdi di inizio e identificativi con la
> scritta T2 su sfondo verde. Inoltre compare in
> elenchi ufficiali di autostrade come questo:
> 
> http://www.aiscat.it/pubblicazioni/downloads/AISCAT-mensile_11-2018.pdf
> 
> 
> Il pezzo tra Aosta e l'inizio del traforo invece fa
> parte della ex SS27.
> 
> Ciao,
> 
> Andrea
> 
> 
> 
> On Tue, Mar 12, 2019 at 3:53 PM Ilario Valdelli
> mailto:valde...@gmail.com>> wrote:
> 
> Onestamente anche la parte Italiana non e'
> autostrada.
> 
> L' autostrada finisce ad Aosta.
> 
> L'ho fatto piu' volte e mi sembra a tutti gli
> effetti una strada normale che attraversa paesi
> e non ha il separatore per corsie.
> 
> On Tue, 12 Mar 2019, 11:59 Volker Schmidt,
> mailto:vosc...@gmail.com>>
> wrote:
> 
> Quello che non so (non avendo fatto la
> galleria, solo il passo) se la transizione
> motorway <> primary
> a) è segnalato sul terreno (in galleria da
> qualche parte, suppongo)
> b) dove si trova di preciso.
> In prima approssimazione si potrebbe mettere
> sul confine, ma forse c'è fra la comunità
> qualcuno che conosce meglio la situazione
> sul terreno.
> 
> On Mon, 11 Mar 2019 at 21:54, Andrea
> Musuruane  > wrote:
> 
> Ciao,
>    Non so quanto sia una edit war.
> Qualche settimana fa mi ero accorto che
> il T4 era stato declassificato a primary
> e avevo commentato il relativo  chageset
> (fatto da un mapper - probabilmente
> olandese - con un centinaio di commit in
> OSM), senza ricevere risposta:
> 
> https://www.openstreetmap.org/changeset/64323526#map=13/45.8613/7.1709
> 
> Poi l'utente lorenzo2002, in modo
> indipendente, ha ripristinato la situazione.
> 
> Detto questo, condivido quanto scritto
> da Volker. La parte italiana è
> autostrada e quindi secondo me era
> corretto il tag 

Re: [OSRM-talk] integer overflow with weight

2019-03-10 Thread michael spreng
On 27/02/2019 20:34, michael spreng wrote:
> Hi
> 
> I currently have OSRM often stopping on the assert:
> BOOST_ASSERT(to_weight >= weight);
> in relaxOutgoingEdges in routing_base_mld.hpp
> 
> looking into it with a debugger shows to_weight = -1958185565 and weight
> = 1418390085 which means that shortcut_weight was probably 918391646
> which lead to an overflow.
> 
> I use forward/backward_rate from 0 up to 1.2 so I thought that should
> not be excessive? What could be the problem?
> 
> What could be a workaround for this overflow? ++destination; continue;?
> 
> A stack trace is below this message.
> 
> Michael
> 

Hi

I could solve this by multiplying forward/backward_rate by 10. A bit
counter intuitive, the lower the rate, the bigger the weight of a route.
And that weight just overflowed. So It seems better to centre the _rate
around 10 than around 1, and never go below a rate of 1 maybe.

Hope that helps
Michael

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


[OSRM-talk] integer overflow with weight

2019-02-27 Thread michael spreng
Hi

I currently have OSRM often stopping on the assert:
BOOST_ASSERT(to_weight >= weight);
in relaxOutgoingEdges in routing_base_mld.hpp

looking into it with a debugger shows to_weight = -1958185565 and weight
= 1418390085 which means that shortcut_weight was probably 918391646
which lead to an overflow.

I use forward/backward_rate from 0 up to 1.2 so I thought that should
not be excessive? What could be the problem?

What could be a workaround for this overflow? ++destination; continue;?

A stack trace is below this message.

Michael



Thread 6 "osrm-routed" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fe970a9b700 (LWP 31177)]
0x76089428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x76089428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7608b02a in __GI_abort () at abort.c:89
#2  0x769cc84d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x769ca6b6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x769ca701 in std::terminate() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x01158ac2 in (anonymous
namespace)::assertion_failed_msg_helper (expr=expr@entry=0x1267c25
"to_weight >= weight", msg=msg@entry=0x1265491 "",
function=function@entry=0x12a80c0 (osrm::engine::datafacade::ContiguousInternalMemoryDataFacade
const&,
osrm::engine::SearchEngineData::QueryHeap&,
unsigned int, int, osrm::engine::PhantomNodes)::__PRETTY_FUNCTION__>
"void
osrm::engine::routing_algorithms::mld::relaxOutgoingEdges(osrm::engine::DataFacade&,
typename osrm::engine::SearchEngineData::QueryHeap&, NodeID,
EdgeWeight, Args ...) [with"..., file=file@entry=0x126e1c8
"/srv/osrm/osrm-backend/include/engine/routing_algorithms/routing_base_mld.hpp",
line=line@entry=284)
at /srv/osrm/osrm-backend/src/util/assert.cpp:19
#6  0x01158ae9 in boost::assertion_failed
(expr=expr@entry=0x1267c25 "to_weight >= weight",
function=function@entry=0x12a80c0 (osrm::engine::datafacade::ContiguousInternalMemoryDataFacade
const&,
osrm::engine::SearchEngineData::QueryHeap&,
unsigned int, int, osrm::engine::PhantomNodes)::__PRETTY_FUNCTION__>
"void
osrm::engine::routing_algorithms::mld::relaxOutgoingEdges(osrm::engine::DataFacade&,
typename osrm::engine::SearchEngineData::QueryHeap&, NodeID,
EdgeWeight, Args ...) [with"..., file=file@entry=0x126e1c8
"/srv/osrm/osrm-backend/include/engine/routing_algorithms/routing_base_mld.hpp",
line=line@entry=284)
at /srv/osrm/osrm-backend/src/util/assert.cpp:28
#7  0x01211d37 in
osrm::engine::routing_algorithms::mld::relaxOutgoingEdges (facade=..., forward_heap=...,
node=node@entry=12463, weight=weight@entry=1418390085)
at
/srv/osrm/osrm-backend/include/engine/routing_algorithms/routing_base_mld.hpp:284
#8  0x01211dd9 in
osrm::engine::routing_algorithms::mld::routingStep
(facade=..., forward_heap=..., reverse_heap=...,
middle_node=@0x7fe970a99408: 4294967295,
path_upper_bound=@0x7fe970a9940c: 2147483647,
force_loop_forward=force_loop_forward@entry=false,
force_loop_reverse=false)
at
/srv/osrm/osrm-backend/include/engine/routing_algorithms/routing_base_mld.hpp:372
#9  0x01213c9e in
osrm::engine::routing_algorithms::mld::search (
engine_working_data=..., facade=..., forward_heap=...,
reverse_heap=..., force_loop_forward=force_loop_forward@entry=false,
force_loop_reverse=false,
weight_upper_bound=2147483647) at
/srv/osrm/osrm-backend/include/engine/routing_algorithms/routing_base_mld.hpp:427
#10 0x01231512 in
osrm::engine::routing_algorithms::directShortestPathSearch
(engine_working_data=...,
facade=..., phantom_nodes=...) at
/srv/osrm/osrm-backend/src/engine/routing_algorithms/direct_shortest_path.cpp:82
#11 0x01177b76 in
osrm::engine::RoutingAlgorithms::DirectShortestPathSearch
(
this=this@entry=0x7fe970a99b30, phantom_nodes=...) at
/srv/osrm/osrm-backend/include/engine/routing_algorithms.hpp:176
#12 0x011e813a in
osrm::engine::plugins::ViaRoutePlugin::HandleRequest
(this=this@entry=0x1483724, algorithms=..., route_parameters=...,
json_result=...)
at /srv/osrm/osrm-backend/src/engine/plugins/viaroute.cpp:119
#13 0x011897cb in
osrm::engine::Engine::Route
(this=0x1483710, params=..., result=...)
at /srv/osrm/osrm-backend/include/engine/engine.hpp:91
#14 0x010fcb4a in osrm::server::service::RouteService::RunQuery
(this=0x147fee0, prefix_length=18,

query="114.0440677,22.3131517;-1.9914632,52.7475385?hints=T816hmfNeoYAHQcAAFQD",
'A' ,
"MA9rkGLoyNBAACvUgAD_5wj-yvksAFhqSP7zumwAQEADwr2S3U1;OQm4gI4JuIDhBPkDAABiFwAAqqtv"...,
result=...) at
/srv/osrm/osrm-backend/src/server/service/route_service.cpp:69
#15 0x0102658f in osrm::server::ServiceHandler::RunQuery

[OSRM-talk] wrong "rate" in debug tiles

2019-02-24 Thread michael spreng
Hi

I am adapting my profiles to use distinct speeds and rates. For
debugging, I wanted to display the rate as well in the debug map view.
However, the rate delivered in the .mvt tiles seems wrong, and I can't
figure out why. In one profile, it is off by a factor of 100, in another
it is off by a factor of about 1.8. strange.

What is forward_weight_range in tile.cpp[1] and how does it work? I have
a feeling that there is some global scaling somewhere which is missing.

Michael

[1]
https://github.com/Project-OSRM/osrm-backend/blob/master/src/engine/plugins/tile.cpp#L482

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


[OSM-talk] Subscription of OSMF members to the osmf-talk mailinglist

2019-02-10 Thread michael spreng
Hi


As it was recently brought up in discussion, I want to clarify the
situation with the osmf-talk mailing list subscriptions.

Previously, new OSMF members were automatically subscribed some time
after signing up. I don't know how timely that was done before the
current iteration of the membership working group. But since about 2016,
new members were signed up in rather large badges: about once or twice a
year, an export was done from the membership register with new
memberships since the last time, and mass subscribed to the osmf-talk
mailing list.

Since the end of 2017, I ceased to automatically subscribe new members.
Instead, they are pointed to the mailinglist with the new welcome
message [1] which is sent to new members after sign up. As you can see,
the first sub topic there is "Participate in our OSMF-talk Mailing list".


What is the osmf-talk mailinglist:

The OSM foundation (OSMF) runs a mailing list for discussing OSM
*foundation* related matter (the OSMF is the formal legal entity
licensing the data and owning the database servers). As a community
project, the foundation should be steered by the community. In that
regard, that mailinglist is a central communication hub for the OSMF
members to discuss among themselves.

Why there is no automatic subscription anymore:

There was quite a bit of negative feedback. People expect to be informed
about OSMF matters, but being thrown into an ongoing debate was rather
unexpected and uncomfortable for many. Maybe too time consuming to deal
with just for being a member. So I proposed in the MWG that we do no
longer automatically subscribe people, but rather invite them to
subscribe themself. The MWG accepted that change and that is the current
status.
The plan is to have somewhat regular "news" posts from the OSMF, or more
specifically communications working group. Those news are probably a
more common format for a membership organisation, summarizing rather
than overwhelming some members with a detailed discussion and being
exposed to everything.

greetings
Michael from the membership working group

[1] https://join.osmfoundation.org/welcome-to-the-openstreetmap-foundation/

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


[Talk-de] Erinnerung an den fristgerechten OSMF-Beitritt für die OSMF-Vorstandswahl

2018-11-16 Thread michael spreng
On 16/11/2018 17:33, Michael Reichert wrote:
> Warum da Paypal steht, weiß ich nicht. Ich hatte nämlich per Überweisung
> bezahlt. :-/
ups sorry, da hab ich mich verklickt. Aber es ist eh egal was da steht,
wir verwenden das Feld nicht.


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


[OSM-talk] additional routing server on osm.org

2018-06-13 Thread michael spreng
Hi

I am the admin of routing.openstreetmap.de and would like to propose to
add it to the directions back ends selectable on openstreetmap.org

routing.openstreetmap.de is sponsored by FOSSGIS, the German local
chapter. It runs OSRM with a car, bike and foot profile. For more
information see https://routing.openstreetmap.de/about.html.

If you find issues you can report them here on the mailing list, or on
github: https://github.com/fossgis-routing-server/routing-chef

best regards
Michael

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


[OSM-talk] FOSSGIS routing server

2018-03-04 Thread michael spreng
Hi

I want to introduce the FOSSGIS routing server at
https://routing.openstreetmap.de/ to a wider audience.
It runs OSRM with a car, bike and foot profile almost worldwide. It
seems to be working quite stable now, so I hope to increase the traffic
a bit. The aim in the end is to get it on osm.org as one of the routing
options. Currently there are only the servers run by commercial
entities, this server should be more community run.

Currently the bike profile is limited to Eurasia, because the servers
are lacking a few GB of ram to run all three profiles world wide.

You can find a bit more information on the about page
https://routing.openstreetmap.de/about.html

Please provide feedback if something is not working as intended. Here or
on github. Also, I am looking for someone else to join me in
administrating these servers, such that they are not depending on a
single person :). If you have a bit of experience working in a shell and
would like to tinker with a big server, don't hesitate to contact me.

Michael

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


Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

2018-01-13 Thread michael spreng
Hi

> correctly then it is not automatic. It is posted from other tool/site
> but allowing this is a purpose of API.
> 
> Is there any evidence that these
> comments are spammy or used in de-facto automatic fashion? Os its it
> really automatic and I misunderstand situation.
> 

I just tried it myself on OSMCha:

-I needed to log in again, and OSMCha now requests the permission to
edit the map.
-after log in I am presented with a pop up on the bottom right, stating
that osmcha will now comment on changesets that I reviewed.

I marked a changeset of an experienced mapper as good, and after that,
the changeset comment appears on the changeset page, without further
interaction from my side.
I immediately felt obliged to apologize for the comment, because that
was an experienced mapper.

So I agree that the comments are too automatic.

The reviewer should be presented with the choice to comment (or not)
each time, and have the opportunity to change the message. Especially
because this is one of the rare cases that go directly to the users
email inbox! If this gets used a lot, mappers will be trained to ignore
messages from OpenStreetMap. This being viewed as spam is a concern for
me as well.

Michael

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


Re: [Talk-de] routing.openstreetmap.de

2018-01-05 Thread michael spreng
Hallo

On 31/12/17 15:05, Toni Erdmann wrote:
> Ausgerechnet meine erste Route war sehr komisch.
> 
> 'Bike'
> 
> von 'Rosenheimer Landstraße 44; Ottobrunn, Landkreis München, Upper
> Bavaria, Bavaria, 85521, Germany'
> 
> nach 'A2J7D9, Avenue du Général de Gaulle, Pen ar Ru, Tachen An
> Hospital, Lannion, Côtes-d'Armor, Brittany, Metropolitan France, 22300,
> France'
> 
> aber, ja mei, warum net.
> 
Der Bug mit den Fähren sollte nun behoben sein.

Grüsse
Michael

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


Re: [Talk-de] routing.openstreetmap.de

2018-01-03 Thread michael spreng
Hallo Jakob

On 31/12/17 14:29, Jakob Mühldorfer wrote:
> 
> Eine Frage zu diesem Teil:
> 
>> mit OSRM — mit Auto-, Fussgänger- und Bike-Profil
> Dies sind die standard Profile, unverändert von OSRM übernommen?
> 

Ist schon etwas an die OSRM profile angelehnt, aber doch recht anders.
Bis ich die Dokumentation fertig habe, schaut mal
https://github.com/sosm/cbf-routing-profiles an: car, foot-city und
bike-city
Die wurden ursprünglich mal von Sarah Hoffmann gemacht.

Grüsse
Michael

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


Re: [Talk-de] routing.openstreetmap.de

2018-01-03 Thread michael spreng

On 31/12/17 15:05, Toni Erdmann wrote:
> Am 30.12.2017 um 00:45 schrieb michael spreng:
>> Hallo
>>
>> Unter https://routing.openstreetmap.de/ gibt es nun weltweites Routing
>> mit OSRM — mit Auto-, Fussgänger- und Bike-Profil. Die Server sind von
>> FOSSGIS gesponsert und wurden von mir in den letzten paar Wochen
>> eingerichtet. Der eine Server rechnet basierend auf dem jeweils
>> aktuellen OSM-planet die Graphen aus, während der andere die Daten
>> ausliefert. Der Update-Zyklus ist im Moment etwa ein Tag. Probiert es
>> doch mal aus.
>>
>> Beste Grüsse
>> Michael
> 
> Danke Michael,
> 
> sieht gut aus und gefällt mir.
> 
> Ausgerechnet meine erste Route war sehr komisch.
> 
> 'Bike'
> 
> von 'Rosenheimer Landstraße 44; Ottobrunn, Landkreis München, Upper
> Bavaria, Bavaria, 85521, Germany'
> 
> nach 'A2J7D9, Avenue du Général de Gaulle, Pen ar Ru, Tachen An
> Hospital, Lannion, Côtes-d'Armor, Brittany, Metropolitan France, 22300,
> France'
> 
> aber, ja mei, warum net.
> 
> Gibt es die Möglichkeit einen "Permalink" zu generieren, den man
> "teilen" kann?
> 
> Mit "refresh" im FF kommt dann das Folgende in die Adresszeile:
> 
> https://routing.openstreetmap.de/?z=6=48.290503%2C11.403809=48.065289%2C11.660743=48.728157%2C-3.460500=en=0=1
> 
>

Hallo

Ah schon wieder dieser Fähren Bug. Ich hoffe, dass ich den bald
beseitigt habe.

Ja der Link in der Adressleiste ist ein Permalink.

Grüsse
Michael

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


Re: [Talk-de] routing.openstreetmap.de

2017-12-30 Thread michael spreng

On 2017-12-30 07:22, Tobias wrote:

Hi,

Danke für die Info...
Kann das Routing was besonmderes???



Hallo Tobias

Das Besondere ist hauptsächlich, dass der Server Community-betrieben 
ist. Die anderen sind so viel ich weiss von Firmen. Das heisst wir 
können die Routing Profile auch als Community pflegen. Zusätzlich ist 
das bis jetzt der einzige öffentliche OSRM Server mit Bike und 
Fussgänger Profil den ich kenne. Dokumentation wird dann noch folgen, 
damit alle auch mitwirken können.


Grüsse
Michael

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


[Talk-de] routing.openstreetmap.de

2017-12-29 Thread michael spreng

Hallo

Unter https://routing.openstreetmap.de/ gibt es nun weltweites Routing 
mit OSRM — mit Auto-, Fussgänger- und Bike-Profil. Die Server sind von 
FOSSGIS gesponsert und wurden von mir in den letzten paar Wochen 
eingerichtet. Der eine Server rechnet basierend auf dem jeweils 
aktuellen OSM-planet die Graphen aus, während der andere die Daten 
ausliefert. Der Update-Zyklus ist im Moment etwa ein Tag. Probiert es 
doch mal aus.


Beste Grüsse
Michael

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


[OSRM-talk] ferry routing problem

2017-11-01 Thread michael spreng
Hi

We have a problem on routing.osm.ch, that a ferry is used too often,
even though I set the speed of the ferry very low, such that it should
only be used if there is an exceptionally long detour without it. Here

http://routing.osm.ch/?z=14=46.696227%2C7.941270=46.709618%2C7.962899=46.688088%2C7.898548=en=0=2

I would assume that it takes the road along the shore, because it has a
four times faster speed. But the routing uses the ferry never the less.
See https://routing.osm.ch/debug/bike-touring.html#14/46.6975/7.9469 for
the speeds.

Another problem I have is with the foot profile, where the ferry does
not show up in debug:
https://routing.osm.ch/debug/foot.html#14.42/46.7076/7.9472

But it is obviously in the routing graph, because again it gets
preferred to the way along the shore:

http://routing.osm.ch/?z=14=46.697464%2C7.946935=46.709618%2C7.962899=46.688088%2C7.898548=en=0=3

The profiles can be seen here:
https://github.com/sosm/cbf-routing-profiles

Does someone have some insight on what I'm doing wrong?

Michael

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


Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-03 Thread michael spreng
Yes I support a pause. I feel that currently one side tries to outgun
the other with rather brute force mechanical editing.

Michael

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


Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

2017-01-05 Thread michael spreng
Hi Mikel

I would like to offer a different view on community friendliness.

On 04/01/17 22:18, Mikel Maron wrote:
> Reverts should be held to the same standard as imports (outside of
> obviously urgent problems). That means a well documented and visible
> plan, community discussion. Rob's comment shows that it is not possible
> for someone eyeing a revert to judge this from a quick look at the data
> or discussion on talk@. Right or wrong, the communication I've seen from
> community members making reverts has left a lot of rough feelings. I
> don't believe that this thread meets a community friendly threshold for
> reverts.
As a caring contributor I checked my vicinity with regard to this edit.
After all, it touches all borders. This wastes a lot of time and is not
an activity I like. It was not announced on our local mailing list
talk-ch. Therefore I find this forced edit not community friendly.
> 
> Can we hold off on the current revert regime across the board until we
> have as good guidance and practice in place as we have for Imports?
For the above reason, and reasons mentioned in other posts, I fully
support the good work of the DWG. If people go ahead irresponsibly they
should be sent back in order to keep OSM a place to contribute, and not
just fix data dumps.

Michael


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


Re: [OSM-talk] OSM New Logo Proposal

2016-10-15 Thread michael spreng
Hi

I find the proposed logo quite appealing. Well done. Nevertheless, I
argue against the magnifying glass

On 14/10/16 21:56, Frederik Ramm wrote:
> The magnifying glass is hard to explain when there's nothing
> under it but I think we have reached an age where it is ok to simply
> hold on to something because of tradition ;)

This is a very good point, but the confusion with search outweighs this.
The average person stumbling across a small OSM logo on different sites
will mistake it as search and not even recognize that it is a logo. I
would like to see a small logo which can be put in a corner of the map
to say "hey, this is OSM data" without user experience headaches.

Michael



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


Re: [OSM-talk] Working with lat and long simply

2016-09-10 Thread michael spreng
On 10/09/16 17:43, john whelan wrote:
> However dig it out of the xml code and drop it into Nomination and you
> get an error.  lat='45.472891' lon='-75.4891002'
What kind of error do you get? Works for me:
http://nominatim.openstreetmap.org/search.php?q=45.4729+-75.4891

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


Re: [Talk-de] Semi-OT: Welches GPS fürs Fahrrad?

2016-01-06 Thread michael spreng
On 30/12/15 09:47, Volker Schmidt wrote:
> Habe selbst keine Erfahrung, aber mich wundert, dass keiner ueber Garmin
> edge Touring und edge 1000 spricht. Beide kommen von Hause aus mit
> vorinstallierter OSM Karte (=Garmin Cycle Map) fuer ganz Europa.
Hallo Liste, sorry für die späte Antwort

Ich habe ein Garmin edge 1000 und bin recht zufrieden damit.

- Hat ab Fabrik OSM drauf
- Display ist gut lesbar, auch in direktem Sonnenlicht sogar ohne backlight.
- sehr guter Standby Modus (praktisch keine Batterieentladung über einen
Monat)
- akzeptabler, stabiler GPS Empfang

nicht so toll finde ich:

- das UI ist für Sportwahnsinnige entwickelt. Viele Features an
vorderster Front die ich nie haben wollte, anderes dafür 3-4 Berührungen
entfernt, wie z.B. Anzahl und Signalstärke der Satelliten
- zeichnet kein gpx auf, sondern .fit Dateien, welche eine neue Version
(oder ein Patch) für gpsbabel brauchen.
- Routing funktioniert für mich nicht so gut. Ich denke das liegt vor
allem an der Gewichtung verschiedener Strassentypen. Ausser selber
Karten generieren mit mkgmap kann man da wohl nicht viel einstellen.
- Kartenupdates von Garmin brauchen einen Windowsrechner und die
proprietäre Garmin Software. Welches ungefragt all meine gps traces hoch
geladen hat! Grrr! Das ist wirklich eine Katastrophe für sich.
Kartenupdates aus anderen Quellen kann man aber bequem per USB
Massenspeicher Anbindung auf das Gerät kopieren.

Grüsse
Michael

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


Re: [OSM-talk] Nominatim is awesome

2015-12-14 Thread michael spreng
On 14/12/15 18:14, John Goodman wrote:
>> Please avoid being gratuitously offensive by describing something
>> that lots
>> of volunteers have put countless hours into as "braindead".
>
> No offense meant; it just seemed an apt term for a search algorithm
> that favors matches 15,000 km away from one right in the area of
> obvious interest.
>
This still sounds rather silly.
It is your definition of important, your important is not everyone's
view of important.
Nominatim has a rather large back log of a lot more helpful and
important features and fixes, with very few around to actually keep it
running. This thread feels not important in contrast to many other things.

I'm unfortunately not donating time to develop Nominatim. Non the less
this thread feels strange. It is good to voice issues, but please accept
the answer. Not much good comes of repeating how some think the
priorities are not set right.

Do it, don't keep talking about it. (By which I mean make an
implementation, and see it fail lots of times until you get it right. It
is a rather complex topic.)

Michael

P.S: John please do not top-post. Each of your mails started a new
thread in the mails.


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


Re: [OSM-talk] Layers and landuse

2015-06-27 Thread michael spreng
On 27/06/15 10:40, Ture Pålsson wrote:
 I recently taught my rendering hack about the ’layer’ tag, and
 immediately encountered a set of new problems. For example, consider
 this ditch: http://www.openstreetmap.org/way/243331898 . It has
 layer=-1, probably to indicate that is passes under the road which it
 crosses. However, it is entirely covered by a landuse=farmland with no
 layer tag, which I take to mean an implicit layer=0. This means that
 my renderer now renders the farmland over the ditch, completely hiding
 the latter. Meanwhile, Mapnik obviously does what the tagger intended.

 Is this a tagging error, that I should fix by editing the data, or is
 it something that my renderer should be able to cope with?

This is not a tagging error. You should have different sets of layers
for different things. Usually areas are in a lower set of layers than
lines, meaning that all areas are rendered below lines. This makes
tunnels visible below a forest and similar things. And also your example
is covered by this.

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


Re: [Talk-transit] validator rule for public_transport=platform

2015-05-07 Thread michael spreng

Hi

On 2015-05-07 10:13, Jo wrote:


I'm getting messages from the validator claiming 
public_transport=platform

can only be used on way or closed_way. This is not true. It can be used
perfectly well on nodes. In that case the node represents the position 
of

the pole.


A platform is not a pole...


I just checked it on the wiki.


The public transport schema has a lot of history, I don't know if I want 
to trust the wiki on that.



highway=bus_stop
public_transport=platform
bus=yes



I would rather drop the public_transport=platform for poles. I agree 
that highway is misleading. But do we really need to additionally 
explain that a platfrom is a pole?


Kind regards
Michael

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


Re: [OSM-talk] Keeping imported data updated with source changes

2015-01-11 Thread michael spreng
Hi Wiktor

I maintain an import of public transport stops in Switzerland. These
public transport stops have a unique identifier (uic_ref) which is used
for example in time table applications, so we include it. But I spend
quite a bit of time maintaining these refs, as mappers usually don't
know and care about them.
I understand your reasoning but I would advise against introducing this
reference in your Import. It doesn't feel right in the OSM database and
it will cause quite a bit of work to keep them tidy.

That being said maybe you shouldn't aim at a 100% solution. It is very
kind of you to want to make it perfect, but I think a solution which is
a little bit simpler but which misses a few corner cases will be all
right. (Making the corner cases miss some data to import, not destroy
OSM data)

I'm biased, because I maintain the tool, but: I think it helps the power
mappers to have a map where they can compare OSM data with the other
datasource (see http://didok.osm.ch). It shows a few things: it shows
stops which are only in OSM, and in a different colour stops which are
only in the data source. And it shows a line between OSM data and the
data from the other source, making it easily visible where something is
wrong. It also has a separate database where one can mark stops as
invalid, something you will probably need as well.

And then, from time to time, I propose some specific mechanical edits
fixing things that are often wrong in OSM. Of course this leaves a lot
of manual work, and I'm lagging behind considerably.

I hope that helps, I wish you a lot of success with maintaining Polands
addresses.
Michael

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