Re: [OSM-talk] Active maintenance on opening_hours tag?

2024-03-03 Thread Maarten Deen
 

> Op 04-03-2024 08:13 CET schreef Mateusz Konieczny via talk 
> :
>  
>  
> Mar 3, 2024, 20:32 by iboa...@gmail.com:
> 
> > 
> > I was wondering, are there any automatic maintenance bots or anything that 
> > run periodically to detect and maybe try to clean up errors?
> > 
> That would require mistake opening hours that are broken and at the same 
> obviously
>  
> I am not aware about either potential for fixes or about running bots.
>  
> Though if there is source data available that we can use then 
> imports/comparing
> with shop-provided data can work, and there are/were some imports like that.
> 
The JOSM validator has such a check. Obviously it only checks the format, not 
if the times are correct.
 
https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/validation/tests/OpeningHourTest.java
 
Regards,
Maartem
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

2023-11-02 Thread Maarten Deen

> Op 02-11-2023 09:57 CET schreef Marc_marc :
> Le 02.11.23 à 08:09, Maarten Deen a écrit :
> > terre_battue => gravel
> 
> this one is wrong, the correct fix was already in the previous list
> terre_battue clay for tennis pitch, earth for others

Ah, in dutch we call that gravel as well. I see in english it is called a clay 
pitch. I just assumed because gravel is an english term it was called that in 
english too.

Maarten

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


Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

2023-11-02 Thread Maarten Deen
I have a few suggestions too:
 
verdichtet => compacted
straatstenenc => paving_stones
bestraat => paving_stones
niet-bestraat => unpaved
niet-bestraat2 => unpaved
niet-bestraat33 => unpaved
щебеночное_покрытие => gravel
no_paved => unpaved
concreteas => concrete
Pflastersteine => sett
pflastersteine => sett
Bosbodem => dirt
klinkers => sett
sans_revêtement => unpaved
schotter => gravel
Turf => turf
holz => wood
грунт => dirt
terre_battue => gravel
плитка => paving_stones
pavingstones => paving_stones
não_pavimentado => unpaved
Waldboden => ground (literally forest soil)
permukaan tanah dan Beton means ground and concrete
 
And I want to point attention to surface=앿
https://www.openstreetmap.org/way/1185643877
Seems someone is adding this in Taiwan a lot. I think it means unpaved.
 

> Op 01-11-2023 23:42 CET schreef Mateusz Konieczny via talk 
> :
>  
>  
> I proposed some time ago to fix some surface values.
>  
> Edit is documented at
> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_surface_tags
>  
> I propose to expand this by fixing also values listed below.
>  
> Please comment if any of proposed replacements are dubious in any way and 
> do not qualify for a replacement with an automated edit.
>  
> Please also comment if you checked values proposed to be edited and they seem 
> fine!
>  
> Edit will affect around 2200 objects.
>  
> It is preferable to use standard tag values where possible,
> and in many cases unusual values can be migrated without any data loss.
> The list below is supposed to contain only such cases.
>  
> If anyone wants I can help them to find affected objects or present listing of
> edits which added this tags or list people who added this values onto 
> currently
> tagged osm objects.
>  
> Samples of this values were tested. I also asked for review at 
> https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419
>  
> Tried to use them as detectors of bogus data, neither were really useful for 
> this purpose.
> We have many better ways to find OSM data requiring human review.
>  
> So I am proposing following changes
>  
> tags with highest use, among ones that will be retagged
> surface = astroturf with 297 uses
> surface = timber with 122 uses
> surface = paving with 179 uses
> surface = U with 82 uses
> surface = enrobé with 276 uses
> surface = terre with 383 uses
>  
>  
> surface = astroturf → surface = artificial_turf
> surface = timber → surface = wood (see 
> https://www.openstreetmap.org/changeset/66866027 
> https://www.openstreetmap.org/changeset/126078123 
> https://www.openstreetmap.org/changeset/126078123 
> https://www.openstreetmap.org/changeset/68461319 
> https://www.openstreetmap.org/changeset/69445813 
> https://www.openstreetmap.org/changeset/57280475 
> https://www.openstreetmap.org/changeset/126800407 )
> surface = DIRT → surface = dirt
> surface = paving → surface = paved
> surface = U → surface = unpaved
>  
> French from 
> https://lists.openstreetmap.org/pipermail/talk/2023-April/088164.html
> review at 
> https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419
>  
> surface = enrobé → surface = asphalt
> surface = béton_bitumineux → surface = asphalt
> surface = béton_bitumimeux → surface = asphalt
> surface = bitumen → surface = asphalt
> surface = enrobes → surface = asphalt
> surface = bitume → surface = asphalt
> surface = goudronné → surface = asphalt
> surface = gourdon → surface = asphalt
> surface = plastique → surface = plastic
> surface = banc_de_sable → surface = sand
> surface = terre → surface = earth
> surface = Terre → surface = earth
> surface = terre_boue → surface = mud
> surface = terre_humide → surface = mud
> surface = terre,_boue → surface = mud
> surface = graviers → surface = gravel
> surface = tere → surface = earth
> surface = terre2 → surface = earth
> surface = caoutchouc → surface = rubber
> surface = bois → surface = wood
> surface = béton_désactivé → surface = concrete
> surface = terre_batue → surface = clay
> surface = pavés → surface = paved
> surface = carrelage → surface = tiles
> surface = pelouse_et_terre → surface = grass;ground
> surface = terre_touvenant → surface = ground
> surface = terre;herbe → surface = ground;grass
> surface = terre_naturelle,_argileuse → surface = ground
> surface = gravier → surface = gravel
> surface = gazon_synthétique → surface = artificial_turf
> surface = béton → surface = concrete
> surface = ciment → surface = concrete
> surface = herbe → surface = grass
> surface = gazon → surface = grass
> surface = herb → surface = grass
> surface = herbe_naturel → surface = grass
> surface = pelouse → surface = grass
> surface = pelouse_naturelle → surface = grass
> surface = terre_et_rochers → surface = ground;rock
> surface = béton_bois → surface = concrete;wood
> surface = terre,_cailloux → surface = 

Re: [OSM-talk] When two bots go to war

2023-09-12 Thread Maarten Deen
There seems to have been an automated edit to add opening_hours:covid19 
https://wiki.openstreetmap.org/wiki/Key:opening%20hours:covid19?uselang=en-GB=same.
 
I'm a bit curious how this can be an automated edit. Or does the bot take 
external data of objects where the covid19 opening hours are the same?
And are covid19 restrictions still in place in Sweden?
 
Regards,
Maarten

> Op 12-09-2023 10:49 CEST schreef Mateusz Konieczny via talk 
> :
> Sep 12, 2023, 10:41 by marc_m...@mailo.com:
> 
> > Le 12.09.23 à 08:23, Snusmumriken via talk a écrit :
> > 
> > > I recently happen to witness an edit war between two bots, that changed
> > > a tag on an object back and forth once a day
> > > 
> >  
> > id of the object ?
> > 
> https://www.openstreetmap.org/changeset/141053368
>  
> for example https://www.openstreetmap.org/node/8537345577
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

2022-11-28 Thread Maarten Deen
Your remark seems reasonable ;)

Thing is: this is not meant as a bot, so the usual caveats apply. It just 
serves as a highlight of "something might be wrong here", like so many QA tools 
do. What the user wielding the QA tool does with that is his choice.
Does he automatically correct it? Wrong for OSM standards, but who is going to 
stop him. Just like who is stopping anyone using a QA tool and armchairmapping 
something that he really can not see from a distance.

Regards,
Maarten

> Op 28-11-2022 14:15 CET schreef stevea :
> 
>  
> See, saying “seems reasonable” actually seems reasonable, until one realizes 
> one doesn’t truly know.  Ask yourself if others in OSM would agree if “seems 
> reasonable” is good enough to meet OSM’s criteria for data entry:  you’ll get 
> mixed answers, though a sizable number will say “not really good enough.”  
> You might even have a very high degree of confidence…though, ask yourself if 
> you want to navigate (or otherwise rely upon) a map with what amounts to 
> guesswork.  That’s how the camel’s nose (of creeping errors, one datum at a 
> time) gets into the tent (map).  I mean no disrespect to camels.
> 
> I have decades of experience in software quality assurance at top companies 
> (Apple, Adobe…), so I have great respect for Lukas’ tool finding / 
> identifying errors (emphasis on those verbs), it’s what is done after that 
> which matters.  Guesswork?  Mmm, no, I’d prefer not.  Our usual “on the 
> ground verify” (or otherwise equivalent, like “I already know that”) 
> criteria:  yes, much better.
> 
> We’re not quibbling (slightly objecting to trivial matters) here:  these are 
> fundamental decisions each and every mapper makes as they enter data into our 
> map database.  I strive to keep that quality as high as I possibly can, 
> though everything I say here is simply one person’t opinion.  Let’s be 
> careful with power tools:  they’re great at finding / identifying errors, 
> whether they can “fix” the data after that must be carefully considered 
> case-by-case.
> 
> 
> On Nov 28, 2022, at 12:44 AM, Marc_marc  wrote:
> > Le 28.11.22 à 00:43, Dave F via talk a écrit :
> >> a "high confidence" interpolation, from an armchair or anywhere, will lead 
> >> to inaccurate data being added to the OSM database.
> > 
> > if you have a road in 3 segments A B C and A+C have the ssame name,
> > then not only does it seem reasonable to me to add the name on B
> > but also the reply "do a survey" is a dogmatic answer: the ground
> > does not contain a sign every time osm cuts a way because of a change
> > in the number of strips for example.
> > So by survey, you will be reduced to deducing that a segment between
> > 2 others with the same name, probably also has the same name
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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


Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

2022-11-27 Thread Maarten Deen


> Op 28-11-2022 05:18 CET schreef stevea :

> I'll be curious to hear feedback from this, too.  Thanks for your efforts, 
> Lukas:  I genuinely hope they help our map!

I can see a use when you have three consecutive segments of a road, where the 
first and the last are named (the same) and the middle is not. This might 
indicate an omission.
But it is not guaranteed of course.
Every unnamed way that branches or has a junction is difficult to name in an 
armchair way.

Regards,
Maarten

> 
> 
> > On Nov 27, 2022, at 3:43 PM, Dave F via talk  wrote:
> > 
> > Most roads don't have names.
> > 
> > Any comparison has to be done against an authoritative database or on 
> > ground surveying, for the area in which you're searching.
> > 
> > "where the name can be interpolated from neighbouring ways. This allows to 
> > detect and armchair-fix a (small) subset of these cases with high 
> > confidence. "
> > 
> > I have a "high confidence" interpolation, from an armchair or anywhere, 
> > will lead to inaccurate data being added to the OSM database.
> > 
> > Cheers
> > DaveF
> > 
> > 
> > On 27/11/2022 20:16, Lukas Toggenburger via talk wrote:
> >> Hi all
> >> 
> >> As you might know, OSM data contains a lot of highway=* without name=*. 
> >> Check your region using the following query:
> >> 
> >> https://overpass-turbo.eu/?Q=way%0A%20%20%5Bhighway%5D%5B!name%5D%0A%20%20(%7B%7Bbbox%7D%7D)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B
> >> 
> >> I wrote a Python tool (using Sarah Hoffmann's pyosmium) at 
> >> https://gitlab.com/ltog/ohni that is able to detect such highways in a 
> >> planet (extract) file and report the ones, where the name can be 
> >> interpolated from neighbouring ways. This allows to detect and 
> >> armchair-fix a (small) subset of these cases with high confidence. The 
> >> tool is tailored to minimize false-positives.
> >> 
> >> Please check it out and give feedback.
> >> 
> >> Best regards
> >> 
> >> Lukas

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


Re: [OSM-talk-nl] Bot Phone Number Formatting Proposal

2022-06-07 Thread Maarten Deen

Do you have a link to your script and maybe some examples of phone numbers that 
need correcting?



Regards,

Maarten
> Op 06-06-2022 21:11 schreef Marc Zhou Toneu via Talk-nl 
> :
> 
> 
> 
> To whom it may concern,
> 
> 
> I’ve recently written a pythons script that would automatically format the 
> phone numbers in NL should it be wrongly formatted, and I would like to hear 
> your opinion about it.
> 
> 
> So far I am proposing to do the following:
> 
> * Formatting phone numbers according to the ITU-T E.123 format pattern
> * Phone numbers that were not parsable would be left untouched
> * Phone numbers that do not need formatting would be left untouched
> 
> 
> There were some edge cases that I’ve seen so far such as:
> 
> * Having URL links or opening times as phone numbers
> * Having ‘/‘ for indicating multi value tag
> * Phone numbers but with description as part of it, such as ‘10ct/m’ or 
> ‘emergency’
> 
> 
> Phone numbers that would require manual inspection/correction such as the 
> following will be send to map roulette:
> 
> * Phone numbers belonging to other countries
> * Phone number values that is just completely wrong
> 
> 
> Please let me know if you have any concern or objections about it, and I’ll 
> gladly take your feedback into account.
> 
> 
> Kind regards,
> Marc ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] Gedoe rond garmin.openstreetmap.nl

2022-05-04 Thread Maarten Deen
> Op 04-05-2022 11:28 schreef St Niklaas :
> 
> 
> Maarten Deen,
> Er zitten of hangen dan na die opheffing wel weer een aantal losse eindjes in 
> de lucht.
> 
> Bijvoorbeeld; vragen aan OSM.nl komen dan naar verwachting niet meer bij de 
> huidige operator (van dat post adres) terecht  

Als de site niet meer actief is dan zullen er ook geen vragen over komen. Juist 
nu krijg je er vragen over die je niet kunt beantwoorden, behalve met "de site 
wordt niet onderhouden, je moet hem niet gebruiken". > 
> Welke rol speelt Garmin als externe partner in dat verhaal ? Je kunt als 
> vrijwilliger je aangegane afspraken nou eenmaal niet zonder overleg verzaken.


Speelt Garmin hier überhaupt een rol? Heeft Garmin iets met deze site te maken? 
Volgens mij niet.


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


Re: [OSM-talk-nl] Gedoe rond garmin.openstreetmap.nl

2022-05-03 Thread Maarten Deen
IMHO is het hoog tijd om deze site zijn verdiende rust te geven. Hij wordt niet 
gemaintained, de maintainer is niet te bereiken en de site werkt niet meer.

Let it go.

Maarten

> Op 03-05-2022 14:43 schreef Stefan de Konink :
> 
>  
> Hoi,
> 
> Ook even via deze hele actieve mailinglist. Er is vandaag wat gedoe 
> ontstaan rond de 'eerste betaalde medewerker' van de OSM Foundation en 
> ondergetekende. Laten we het er op houden dat deze medewerker actief 
> sponsoren is gaan benaderen om diensten (van ons) af te sluiten.
> 
> Mocht je nog een telefoonnummer van Lambertus hebben, dit is het moment om 
> hem te bellen. Mocht je gedachtes hebben over garmin.openstreetmap.nl (dat 
> al heel lang onbruikbaar is) of andere willekeurige diensten die 
> OSMF-diensten van hogerhand af denk te kunnen sluiten, laat je vooral ook 
> horen.
> 
> 
> 
> -- 
> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl

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


Re: [OSM-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

2020-12-11 Thread Maarten Deen

On 2020-12-10 19:49, Yves via talk wrote:

Niels, Arnalielsewhere post wasn't about mapping, the map is used to
illustrate something.
I agree with others comments pledging for more time to be taken to
read someone else's lines.


Then I struggle to see the relevance. The whole blogpost seems to be a 
call against (apparent) male preference to take the short (and 
dangerous) route, with extension that the male will only take the longer 
less dangerous route to please the female.


I'm not sure how to apply that to OSM governance.
If it is about the points: 1: agree, 2: ok, noted. Which is one of my 
fears when even looking at women, that they see me as someone who wants 
to attack them, just because I look at them (i.e. see them, not "check 
them out"). 3: yes.


So, which path do we choose to take? I can not answer that. I have taken 
my own path in OSM and mapping and I think I added value to OSM using 
that path. I also like to think I have never exhibited offensive 
behaviour to women or others in OSM but that is a statment only others 
can affirm.


So I really struggle to see the relevance. At least in my case. And I 
struggle to see the underlying institutionalized method that seems te be 
felt.
I also have to agree with user_5589's last comment to the blogpost. To 
have certain seats allocated to certain groups of people will give 
others more reason to say "you are only here because we have to have you 
here, not because you have a valuable input on the matter". And that is 
something we very much need to avoid.
It will also weaken OSM if you don't have the best person for the job. 
And that person may be black, white, male, female, straight, gay, 
catholic, muslim, facebook employee or independent, or whatever the 
person identifies as.


Regards,
Maarten

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


Re: [OSM-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

2020-12-09 Thread Maarten Deen
I have been silent about this but when a document is drafted where only 
supporters will be heard, I have to speak out in Frederiks support.
I have seen no systemic aggressive behaviour that demotivates and 
excludes participation by women and minority groups in OSM or behaviour 
that degrades the spirit of open community culture, and damages the 
OpenStreetMap reputation from Frederik.


If you then feel that I am part of the problem, I am saddened and hurt 
by that because I do not feel myself that way. I have never been 
non-supportive of anyone in this community or any other.
I feel this is more a witchhunt than anything else. If you can not make 
an analogy then conversation and discussion is lost and I do not see how 
this comment would degrade women. It degrades the maker of the comment, 
i.e. Trump.


Regards,
Maarten

On 2020-12-09 20:06, Celine Jacquin wrote:

Hello everybody
I hope you are all well

We, several groups, chapters, organizations and individuals, have
reacted to the conversation in the osm-talk-list
(https://lists.openstreetmap.org/pipermail/talk/2020-December/085692.html)
considering that it is an incident symptomatic of the problem we have
faced for many years in the community, which is one of the greatest
obstacles to diversity at all levels of OSM. Time to make a real
change.That is why we have developed a beginning of statement on the
desirable mechanisms to work solidly on the rules of coexistence and
improve diversity.

We bring it to your attention and invite anyone who feels represented
to sign it. Translations are in preparation (any help is welcome):
https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit?usp=sharing

On behalf of the signatories

Best regards

Céline Jacquin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov

2020-10-30 Thread Maarten Deen

On 2020-10-30 10:04, Martin Koppenhoefer wrote:


When digging slightly deeper it surfaces that people who do not want
to sign up at  can only read. "Ask me
anything" in readonly mode?


I'm sure you can send them questions via email 
(https://wiki.osmfoundation.org/wiki/Contact) and I'm hoping the 
participants will monitor their email during the AMA. That should be 
near real-time enough.


The only down part is the countries where reddit is banned completely.

Regards,
Maarten

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


Re: [OSM-talk] Idea for improving mapping system

2020-10-18 Thread Maarten Deen

+1

I'm sorry if I sound a little paranoid, but somone with an email address 
of little.banana.peel and calling him TheAdventurer64 and asking people 
to read something for which they have to log in to with a google account 
does not give the feel for a solid foundation for a discussion.


Regards,
Maarten

On 2020-10-18 06:02, Joseph Eisenberg wrote:

Would you mind describing the proposed system here, in a concise form?

On Sat, Oct 17, 2020 at 7:36 PM TheAdventurer64
 wrote:


Hello everyone,

A user and I were talking about implementing a system for better
mapping, as described here:
https://osmus.slack.com/archives/C029HV951/p1602968516431900
This addition would have many benefits, including:
* More mapping. We have tons of new mappers each day, as well as a
great editor for them. However, many of these new mappers leave
after just a few edits. Examples:
https://www.openstreetmap.org/user/lukastheg03

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

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


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


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

2020-10-13 Thread Maarten Deen
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


Re: [OSRM-talk] Colombia - Tunel de la linea

2020-10-07 Thread Maarten Deen

On 2020-10-02 08:01, Maarten Deen wrote:

Hi Carlos,


In the past days a new tunnel was opened in Colombia "El Tunel de la
linea", which allows to go in one way and the mountain must be crossed
from the other direction; This tunnel is located between the cities
Calarcá and Cajamarca.

OSRM does not allow routing through the most important tunnel in the
country and avoids it by an infrequent path to the north.

 Could you please solve this so that the route goes through "El Tunel
de la linea".


When you take the graphhopper routing, it does use the tunnels. The
only thing not 100% correct I could find is that a lot of roads still
have construction=trunk on them (as well as highway=trunk). If it is
still under construction you use
highway=construction+construction=trunk, when the road opens you have
to remove the construction=trunk. Maybe OSRM gets put off by that?

I've removed construction=trunk from all roads that have
highway=trunk. See if that solves it.


It now routes through the tunnel so I guess removing the 
construction=trunk did the trick.


Regards,
Maarten

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


Re: [OSRM-talk] Colombia - Tunel de la linea

2020-10-02 Thread Maarten Deen

Hi Carlos,


In the past days a new tunnel was opened in Colombia "El Tunel de la
linea", which allows to go in one way and the mountain must be crossed
from the other direction; This tunnel is located between the cities
Calarcá and Cajamarca.

OSRM does not allow routing through the most important tunnel in the
country and avoids it by an infrequent path to the north.

 Could you please solve this so that the route goes through "El Tunel
de la linea".


When you take the graphhopper routing, it does use the tunnels. The only 
thing not 100% correct I could find is that a lot of roads still have 
construction=trunk on them (as well as highway=trunk). If it is still 
under construction you use highway=construction+construction=trunk, when 
the road opens you have to remove the construction=trunk. Maybe OSRM 
gets put off by that?


I've removed construction=trunk from all roads that have highway=trunk. 
See if that solves it.


Regards,
Maarten

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


Re: [OSM-talk] Can you recommend good introduction to JOSM for 100% osm newbie?

2020-09-24 Thread Maarten Deen

On 2020-09-24 08:50, Mateusz Konieczny via talk wrote:

I looked at https://wiki.openstreetmap.org/wiki/JOSM and

https://wiki.openstreetmap.org/wiki/JOSM/Guide and
https://learnosm.org/en/josm/

but I am not fully happy about any of them (a bit too much at one for
someone new)

Why not iD: they want to edit and fix hiking relations, what AFAIK is
not well supported in iD


Well, I only know the very basics in iD (and also Potlatch2). I even 
have problems putting a node because it always wants to continue to a 
way and I don't know how to stop this (believe in Potlatch2).
So every editor has a learning curve, even the ones that are supposed to 
be the easy ones like iD or Potlatch2. Because I've been using JOSM for 
years, I know how to use most if not all of the functions and I shun 
away from iD or Potlatch2 just because I've never familiarized myself 
with them (I don't see the need because they lack the features of JOSM).


I don't see what is "much" about 
https://wiki.openstreetmap.org/wiki/JOSM/Guide. 2 steps to start the 
program (if you have Java installed) and the basic functions are 
explained step by step.
Relations are always a more advanced topic, but I can't imagine that 
with a few days of fiddling around you don't get the hang of it.


Regards,
Maarten

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


[OSRM-talk] OSRM on the openstreetmap homepage does not want to route through Duplex tunnel A86

2020-09-06 Thread Maarten Deen
See 
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=48.9046%2C2.1962%3B48.7810%2C2.1723#map=12/48.8430/2.1665


This routing is not taking the duplex A86 tunnel in Paris. When you 
switch to Graphhopper routing then it is taking the tunnel.
I don't see any obvious errors in the ways. Is this a problem in de 
routing engine?


Regards,
Maarten

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


Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

2020-08-23 Thread Maarten Deen

On 2020-08-23 22:20, Sarah Hoffmann wrote:

Hi,

On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:

Node 3117603944 was established in 2014 with tags
addr:city   Sørkjosen
addr:housenumber45
addr:postcode   9152
addr:street Ringvegen

Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no 
results.


What is going wrong here? Sørkjosen itself is found [2] so the problem 
does
not seem to lie in the special character (I wouldn't have thought so). 
Also
found is the street which is named Ringveien [3] in OSM. No idea why 
the
street is called different than the address node, but does Nominatim 
not

index address nodes?


Nominatim only indexes addresses of streets and then searches for
address nodes based on the address of the street they are attached
to.

In that particular example, the housenumber got attached to Hovedvegen
because Nominatim could not find a 'Ringvegen' and used the nearest
street:
https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944


Just one question though (well two acutally): why does it find 
Hovedvegen as nearest street and not Reingveien 
https://nominatim.openstreetmap.org/ui/details.html?osmtype=W=282670088 
?
And would it be an idea to make some kind of fuzzy matching when 
searching for names? Like "it is better to take a street which has just 
one different letter then one where all differ"?


Regards,
Maarten

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


Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

2020-08-23 Thread Maarten Deen

On 2020-08-23 22:20, Sarah Hoffmann wrote:


Fix the name of the street and everything sorts itself out.


Thanks, I'll sort out the street name with the Norwegian community.

Regards,
Maarten

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


[OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

2020-08-23 Thread Maarten Deen

Node 3117603944 was established in 2014 with tags
addr:city   Sørkjosen
addr:housenumber45
addr:postcode   9152
addr:street Ringvegen

Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no results.

What is going wrong here? Sørkjosen itself is found [2] so the problem 
does not seem to lie in the special character (I wouldn't have thought 
so). Also found is the street which is named Ringveien [3] in OSM. No 
idea why the street is called different than the address node, but does 
Nominatim not index address nodes?


The reason why I was looking for this node is because it has a Tesla 
supercharger [4] on address 45 Ringvegen 9152 Sørkjosen.


[1] https://www.openstreetmap.org/node/3117603944
[2] https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen
[3] 
https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen+ringveien
[4] 
https://www.tesla.com/nl_NL/findus/location/supercharger/sorkjosensupercharger


Regards,
Maarten

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


Re: [OSM-talk] This needs to be voted upon.

2020-08-10 Thread Maarten Deen
I also don't want to imply that a vote is imminent, just that this is 
such a big issue, it can not be decided by mere consensus on a 
mailinglist. Not everyone follows these discussions (not that everyone 
reads the wiki though, but again, this is a major thing).


Regards,
Maarten

On 2020-08-10 08:06, stevea wrote:

I didn't mean to convey or imply that a vote was impending, moreso
that I seriously disagree with the proposal as unneeded, unnecessary,
poorly explained as to its benefits, and (as was well described
before, though I paraphrase), "a ready-made answer for a non-problem."
 My apologies if anybody got the wrong impression that this was up for
a vote.  Rather, here and now it is being discussed, my "No" was
merely my opinion IF it went to a vote.  Better stated, I disagree
with the proposal, as I see no need for it, it is over-engineered, it
has no clear merit, it is confusing, it seems to be more trouble than
it is worth and I feel it would chase away novice volunteers as "too
complex."  The consensus, with the exception of the proposer, seems
100% in line with my opinions.  I do welcome more discussion, that's
why we type here.

SteveA

On Aug 9, 2020, at 11:01 PM, Mateusz Konieczny via talk 
 wrote:





Aug 10, 2020, 07:49 by md...@xs4all.nl:
On 2020-08-10 03:32, stevea wrote:
On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
The discussion below spawned the following idea of migrating the whole 
tags system instead.

(an over engineered proposal largely, as Frederick says and I agree
with, goosed by the "hype of linked data.")

I politely vote "No." I don't see the merit (again echoing
Frederick). While I'm only one person and one vote and perhaps a bit
more vocal than most, I feel it important to express the opinion of
"very strongly against."

I certainly hope that if this idea goes towards implementation that 
there will be a vote first. I also don't see the merits so my vote 
will also be no.
Before going to vote it would need to demonstrate some sort of clear 
benefit and

consensus that it is reasonable.

Vote can be gamed in many ways, and even if that proposal somehow 
would won a vote

it still would not improve it a tiny bit.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


[OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)

2020-08-09 Thread Maarten Deen

On 2020-08-10 03:32, stevea wrote:

On Aug 9, 2020, at 5:29 AM, pangoSE  wrote:
The discussion below spawned the following idea of migrating the whole 
tags system instead.

(an over engineered proposal largely, as Frederick says and I agree
with, goosed by the "hype of linked data.")

I politely vote "No."  I don't see the merit (again echoing
Frederick).  While I'm only one person and one vote and perhaps a bit
more vocal than most, I feel it important to express the opinion of
"very strongly against."


I certainly hope that if this idea goes towards implementation that 
there will be a vote first. I also don't see the merits so my vote will 
also be no.


Regards,
Maarten

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


Re: [OSM-talk] [Talk-us] fake, edit, fake map.

2020-06-16 Thread Maarten Deen
Again, take it up with the mapper first. You talk as if the mapper makes 
mistakes on purpose and the only object is to create an incorrect map. 
I'm sure he's not and he just needs to be told not to rely on aerial 
imagery that much.
But again: take it up with the mapper. You have still not commented on 
the changeset. That should be your first step.


Or what do you want to accomplish by posting this on this list.

Regards,
Maarten

On 2020-06-16 23:07, 80hnhtv4agou--- via talk wrote:

How old is the satellite view, do we even know, or are we making a
fake map here.

what about fact checking ?
Tuesday, June 16, 2020 12:58 PM -05:00 from James
:

as have I, I don't live it Africa, made edits there, I certainly
don't live in North Korea, made edits there, I don't live in
Florida, made edits there. What's your point being 100miles away?
Some of these places I have visited, some I haven't

On Tue., Jun. 16, 2020, 1:54 p.m. Hauke Stieler,
 wrote:I made edits from 2000km away from
where I live. But I was there on
vacation. It's possible that these editors were there, even if they
aren't locals ;)

Just be happy about good edits in your region and talk to them if
you
have something to discuss.

Hauke

On 16.06.20 19:24, 80hnhtv4agou--- via talk wrote:

i am trying to make a point here about editors that are 100 of

miles away.




Tuesday, June 16, 2020 12:20 PM -05:00 from Clay Smalley
:

Not sure what it is you're trying to point out here. Have you
started a conversation with the person who made that edit?

On Tue, Jun 16, 2020 at 9:11 AM 80hnhtv4agou--- via Talk-us

>

wrote:

Added a service road.

Edited about  hours ago by

Version #1 · Changeset #86698283


https://imgur.com/gallery/k6Zjnqm




___
Talk-us mailing list
talk...@openstreetmap.org [5]




https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
talk...@openstreetmap.org [5]



https://lists.openstreetmap.org/listinfo/talk-us






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



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




Links:
--
[1] http://roundcube.xs4all.nl/compose?To=james2...@gmail.com
[2] http://e.mail.ru/compose/?mailto=mailto%3amail@hauke%2dstieler.de
[3] http://e.mail.ru/compose/?mailto=mailto%3aclaysmal...@gmail.com
[4] 
http://e.mail.ru/compose/?mailto=mailto%3atalk%2...@openstreetmap.org
[5] 
http://e.mail.ru/compose/?mailto=mailto%3atalk%2...@openstreetmap.org
[6] 
http://e.mail.ru/compose/?mailto=mailto%3atalk%25252...@openstreetmap.org

[7] http://e.mail.ru/compose/?mailto=mailto%3at...@openstreetmap.org
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


Re: [OSM-talk] fake, edit, FAKE map.

2020-06-16 Thread Maarten Deen

On 2020-06-16 18:09, 80hnhtv4agou--- via talk wrote:

Added a service road.

Edited about  hours ago by

Version #1 · Changeset #86698283

https://imgur.com/gallery/k6Zjnqm


If you think it is fake, you first comment on the changeset and ask the 
mapper to explain. Or look at his profile and see if you can get more 
information about the mapper.
If you think the mapper is continuously mapping incorrectly you can 
address the OSMF. But than you need to be able to show some kind of 
dialog with the mapper in question and show that he is repeatedly and 
purpousfully mapping incorrectly.


Regards,
Maarten

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


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

2020-05-28 Thread Maarten Deen

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

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

Isn't this an anomaly?


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

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

Regards,
Maarten

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


Re: [OSM-talk] Planet torrents...

2020-03-13 Thread Maarten Deen

On 2020-03-10 08:07, Maarten Deen wrote:

On 2020-03-07 09:36, Christian Quest wrote:


This week was the first one I had nothing to do (or fix) :)


Do you have scripts for this? (have to ask before I go make one myself)


I made my own script, this is very basic and works for me in Ubuntu with 
transmission. Replace user:pass with the username and password you 
connect to transmission.


$ transmission-remote --auth user:pass -t `transmission-remote --auth 
user:pass -l|grep planet |awk '{print $1}'` -l
$ transmission-remote --auth user:pass -t `transmission-remote --auth 
user:pass -l|grep planet |awk '{print $1}'` --remove-and-delete
$ transmission-remote --auth user:pass -a 
https://osm.cquest.org/torrents/planet-latest.osm.pbf.torrent
$ transmission-remote --auth user:pass -t `transmission-remote --auth 
user:pass -l|grep planet |awk '{print $1}'` -ph all



Explanation:
transmission-remote --auth user:pass -l|grep planet |awk '{print $1}' 
will output the ID of the torrent. I'm only grepping on planet because 
that's the only planet torrent I've got, it would be better to know the 
whole filename or at least grep on .osm.pbf too.


The first command will display the planet file you're now downloading
The second command will delete it from transmission and remove all files 
with it
The third command will add a new tracker from the website. Because you 
want to seed the latest planet, this is easy.
The forth command will set the priority of the tracker on high. This is 
optional of course.


Regards,
Maarten

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


Re: [OSM-talk] Flashing school speed limit sign

2020-03-12 Thread Maarten Deen

On 2020-03-12 03:59, Andrew Harvey wrote:

On Thu, 12 Mar 2020 at 12:51, Paul Johnson 
wrote:


On Wed, Mar 11, 2020 at 8:23 PM Jack Armstrong
 wrote:


How would this be tagged? I can't seem to find anything about this
on the wiki. Perhaps I'm just not looking in the right place.
Thanks.


The sign itself would be highway=traffic_sign,
traffic_sign=maxpseed, maxspeed=traffic_signals.  For the school
zone on the way, that would be maxspeed=* (whatever the maxspeed is
normally when it's not in effect), and
maxspeed:variable=school_zone.


That looks good but how would you mark the variable speed as 20mph?
I've seen people use something along the lines of
`maxspeed:conditional=80 @ wet` to indicate the lower speed for
maxspeed:variable=weather, so something similar could be used here.


maxspeed:conditional=20 @ flashing?
It is free form, so you can fill in anything you like. If it catches on, 
the people who make the navigation will start to use it.


Regards,
Maarten


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


Re: [OSM-talk] Planet torrents...

2020-03-10 Thread Maarten Deen

On 2020-03-07 09:36, Christian Quest wrote:


This week was the first one I had nothing to do (or fix) :)


Do you have scripts for this? (have to ask before I go make one myself)


Do not hesitate to share your own findings if you have tested the
planet torrents !


I've been seeding now for 2 days, 21 hours and have a ratio of 0.43.

Regards,
Maarten

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


Re: [OSM-talk] The benefits of cross-linking OSM and Wikidata

2020-03-05 Thread Maarten Deen

On 2020-03-05 15:39, Rory McCann wrote:

On 05/03/2020 15:25, Sören Reinecke via talk wrote:

couldn't we do a vote about that? Would it be possible for the OSMF to
maintain and coordinate such a voting.


Yes, we _could_.

It would require a 2/3 majority of “active [OSM] contributors”,


"and responds to a request to vote within 3 weeks"


is (intentionally) a large number (about 250,000 at the time of
writing).


Which will limit that number of 250.000 substantially, and will in fact 
limit that number to the number of votes you receive.
If 4 people respond and 3 vote in favor, than that counts as a 2/3 
majority as put forward in item 3 of the license.


Regards,
Maarten

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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-26 Thread Maarten Deen

On 2020-02-26 12:34, Florimond Berthoux wrote:

The problem is not the OSM "default" (there is no default) map.
OSM is *not* a map !

The problem is the data put in name tag of some objects, which are not
respectful with the international idea of the project.


I find it a stretch to say that someone mapping someting and putting in 
the english name is not respectful to the idea of the project. No one 
else but him was bothered enough to put anything in. He mapped it and 
that is more than enough to respect also the international idea of the 
project (i.c. someone not from or near country X did some mapping in or 
near country X).


The problem with the local names is what has already been said a few 
times: which name do you put in? If the object borders 2 countries, will 
it be two names with a / between them? If the objects borders 10 
countries, will it be 10 names with a / between them? If the object is 
the atlantic ocean, what then?
Will it be nothing in the name tag and are we then going to complain 
that the opencarto style falls back to name:en?


I just hope it will not turn into an edit war if there is no answer to 
that.


Regards,
Maarten



Le mar. 25 févr. 2020 à 22:57, Mario Frasca  a
écrit :


I'm afraid that the conclusion you summarize here is not at all
reached.

we have reached the conclusion on the pointless point: "we discuss
in English".

as for the values of the `name` tag:

I prefer to see "Adriatic Sea" rather than nothing.

I prefer "Mare Adriatico" to "Adriatic Sea".

I definitely question the choice of the editor who wrote "Gulf of
Trieste" for a piece of sea that borders with Italy (in an area
where Friuls is a recognized language), and Slovenia.

and I have suggested that the problem would vaporize if we added a
language identifier to the tile request.

I'm very much interested in reading reactions to this.

MF
On 25/02/2020 16:10, Tomek wrote:

W dniu 20-02-25 o 21:52, stevea pisze:

I believe I speak for many, most, or even all of us here (except
Tomek) that "this is a settled matter."
SteveA

Sprawa rozwiązana, każdy mówi w jakim języku chce, a znacznik
“name” z
obiektów międzynarodowych zostanie usunięty, z wyjątkiem mórz
graniczących z państwami.
Dziękuję za dyskusję

La problemo estas solvita, ĉiu povas paroli en iu ajn lingvo; kaj
la
etikedo “name” el internaciaj objektoj estos forigita, escepte
de maroj
apudaj al landoj.
Dankon por diskuto

The problem is solved, everyone can speak in any language; and the
tag
“name” from international objects will be deleted, except of
seas
adjacent to the countries.
Thank you for discussion

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

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

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


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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-25 Thread Maarten Deen

On 2020-02-25 19:15, Tomek wrote:

W dniu 20-02-25 o 18:43, Mateusz Konieczny via talk pisze:



PS: given the choice, I'd probably rather learn Klingon than
Esperanto,
that might give me better chances to find someone I could talk to in

that language after all I assume, esp. in the tech/geek sector ...

 Viaj personaj elektoj ne interesiĝas min. Ĉu mi altrudas al aliaj
homoj lerni la polan? Ĉesu altrudi al mi lerni la anglan.
I'm not interested in your personal choices. Do I force other people
to learn Polish? Stop making me learn English.


You are forcing (or are trying to) me and a lot of others to learn 
Esperanto. That's just the same. More people speak English than 
Esperanto. Then what is the more logical choice?
If you don't want to read english and you have no problem putting every 
mail into a translator, than why not do that?
Just don't get mad if other people do not want to do that. You can't 
force other people to use a translator just because you choose not to 
write in English.


Maarten

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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-25 Thread Maarten Deen

On 2020-02-25 15:36, Tomek wrote:


 Since you don't want to put in the effort of putting the text in the
translator, maybe it's best to unsubscribe from this list?


I don't think so.
The common language on this list is English, as the common language on 
talk-nl is Dutch and on talk-pl is Polish. Why don't I go to talk-pl and 
complain I'm being oppressed because everyone is not using a language I 
can understand.

It doesn't work that way.


Esperanto is a better choice because it takes much less time to learn
it than to learn English.


Can you back that statement up?
And it does not work for me at this point. I already know English, so 
that time has been spent. I have to invest time learning Esperanto. And 
even more: Esperanto is very much an artificial language for me. I can 
watch movies in English and use that to hone my knowledge of the 
language. If there are movies in Esperanto (probably lip-synced which is 
horrible) I have to go out of my way to get them.



Interlingua is a better choice because it tries to be understood by
users of Romance languages.


That may well be, but the fact it never took on says something, doesn't 
it?



why do other users of this list disrespect me?


I don't disrepect you, I'm just ignoring posts in a language I can not 
understand.



People, let's try not to focus on point '2' alone. and again Tomek,
please help us here, do choose a "top 3" language in your
communications.

 This is the dictatorship of the majority.


Good, dus ich ken in mien eige taal kalle? Versteis tich mich dan nog 
altied? En wat als het get lastigere zinne weare?


I'm certain it is not benificial at all if everyone starts using their 
mother language on this list.


Regards,
Maarten

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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-24 Thread Maarten Deen

On 2020-02-23 23:38, Alan Mackie wrote:

This conversation is petty, repetitive and tedious in the extreme, but
as that seems to be the order of the day:


I can not agree more with this message. I am not even trying to read the 
Polish and Esperanto mails. Yes, I am to lazy to put them in a 
translator because I think it is absolutely unnecessary. I am also not 
posting in Dutch because that will pose the same burden on others and I 
don't think that is the best action to do.
I'm sorry if you feel excluded because you can not or refuse read 
english or think you are being oppressed. I feel excluded in every 
project that is done in Chinese and Japanese. But if they feel that is 
the best language to communicate in, than it is not for me.


The OSM wiki has been translated to many many languages but the main 
page in Esperanto is short at best and many pages have no Esperanto 
translation. Maybe your efforts are better directed to creating some 
international (for you meaning: non-English) traction there.


Regards,
Maarten

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


Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo

2020-02-16 Thread Maarten Deen

On 2020-02-15 21:27, Richard wrote:

On Fri, Feb 14, 2020 at 09:38:03AM +0100, Martin Koppenhoefer wrote:
Am Do., 13. Feb. 2020 um 13:42 Uhr schrieb Maarten Deen 
:


>  From wikipedia (if that is an authority)
>
it isn't.


getting better and better: we have now a discussion on the labeling
of Antifa, definition of facism, authority of Wikipedia, what next? 

* less politics is better for OSM
* I would not be happy if anyone could mashup his logo with that of OSM


I was almost going to do a mashup for an Open Source Street Map project, 
with a nice SS logo inside to troll for reactions.

But I think I'd better not.

Regards,
Maarten

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


Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo

2020-02-13 Thread Maarten Deen

On 2020-02-13 12:59, Florian Lohoff wrote:

On Mon, Feb 10, 2020 at 04:57:40PM +0100, Midgard wrote:

Hi,

Someone created a mashup[1] between the logos of OpenStreetMap and 
Antifa, a collective of militant
groups which are known to use violence. This graphic is distributed on 
stickers.[2]


Just nitpicking but "militant groups" is a little far fetched. Antifa 
is

the abbreviation for "Anti fascist" and by no means has anything to do
with militant activities.

Putting the Antifa into the militant left wing edge is polemic of a lot
of right wing, facist or nationalist partys in the rise in a lot of
European countries.


With the risk of starting a political discussion, but you are grossly 
understating the actions of the various antifa groups.

They are generally seen as militant left wing groups.

From wikipedia (if that is an authority) 
https://en.wikipedia.org/wiki/Antifa_%28Germany%29#Government_and_police_monitoring_of_Antifa


The Federal Agency for Civic Education notes that Antifa groups 
sometimes call for violence not only against police or skinheads but 
also against bishops and judges. There are slogans like "antifascism 
means attack", not only against the far right but also against the 
political system of the Federal Republic of Germany


Especially the last portion makes me shun away from antifa as much as I 
do from fascism.


Regards,
Maarten

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


Re: [OSM-talk] Testing torrents for the planet dump

2020-02-09 Thread Maarten Deen

On 2020-02-09 16:17, Christian Quest wrote:

A couple of weeks ago, I've (re) started sharing planet dump files
using Bittorrent to test an alternative way to distribute our planet
dumps to reduce the bandwidth load on the OSMF servers.

Here is a short summary after 2 weeks tests...

The torrents are generated a few hours after the planet dump
availability on planet.openstreetmap.org server (time needed to
download the original file to generate the torrent).


A question about updates of the torrent. The planet changes weekly. 
Suppose I download the plannet using the torrent and then also seed it, 
what happens when the next planet comes available? Do I need to use a 
different torrent to download it again or will the one I have be 
updated?


Regards,
Maarten

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


Re: [OSM-talk] Teaching cyclists how to contribute to OSM

2020-01-20 Thread Maarten Deen

On 2020-01-20 11:10, James wrote:

I find the path way of tagging like Germany & Italy more accurate,
because MUPs aren't favouring anyone, they are paths that can
accomodate cyclists, pedestrians equally and bikes are limited to
20km/h on MUPs as they are not segregated from pedestrians


Oh, interesting to know. In which jurisdictions? And how can the cyclist 
adhere to this since the average cyclist does not have a speedometer?


Maarten



On Mon., Jan. 20, 2020, 4:46 a.m. Alessandro Sarretta,
 wrote:


Hi,

On 20/01/20 10:16, Maarten Deen wrote:

Normal practice in Germany is to make all shared cycle/footpaths
highway=path + bicycle=designated + foot=designated with an

optional

segregated=yes/no.


same situation in Italy (or, at least, in the area where I'm living:

Padova and Veneto).

Ale

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

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


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


Re: [OSM-talk] Teaching cyclists how to contribute to OSM

2020-01-20 Thread Maarten Deen

On 2020-01-20 03:15, Paul Johnson wrote:

On Sun, Jan 19, 2020 at 6:28 PM john whelan 
wrote:


Locally in Ottawa many paths are multiuse there is a path many
kilometers long along the Ottawa river that has a line marked down
the center and is very much used by cyclists but according to NCC
who own the path it is multi-use not bicycles only so is mapped
highway=path.  Most City of Ottawa paths are the same, bicycles are
permitted but they are not cycleways.


Generally speaking I'd consider that highway=cycleway, foot=yes.  Same
with the variation that has lanes but no sidewalks and clearly has
pedestrians walking on it in the Mapillary.  I'd consider it


Normal practice in Germany is to make all shared cycle/footpaths 
highway=path + bicycle=designated + foot=designated with an optional 
segregated=yes/no.


Routers should be able to cope with this.

Regards,
Maarten

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


Re: [OSM-talk] mapping outside Europe

2020-01-07 Thread Maarten Deen

On 2020-01-07 20:53, Mario Frasca wrote:

On 07/01/2020 14:38, Marc Gemis wrote:

Since OSM is a do-ocracy, do not complain, but write the wiki page you
want to see


that's fine, and I've been doing that for Panama, and for Morocco, but
I do not like mapping without having reached a consensus.

for that, we need other mappers to contribute to the discussion, and I
never managed to get any far on this in the wiki (actually, not even
in the changeset comments).  in particular Panama, none of the local
mappers seem to use the wiki,


If they don't use the wiki, then who complains about missing local 
information in the wiki?


Regards,
Maarten

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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Maarten Deen

On 2020-01-07 08:27, Mateusz Konieczny wrote:

6 Jan 2020, 16:35 by dieterdre...@gmail.com:


sent from a phone

On 6. Jan 2020, at 07:29, Maarten Deen  wrote:

Baltic Sea to be the "Baltic Sea" or for South America to be "South

America" - this is an example of English imperialism.

This "imperialism" idea of yours is just your idea. It is not
something that is widely felt.


regarding imperialism, I think it’s hard to reject the reasoning
that English is in widespread use because of imperialism.

Yes, but using it for a pragmatic reasons
for an international communication is
usually not imperialism.


I am also not a fan of blaming history for the current situation and 
taking the long road because you don't like that history.
It would mean that I couldn't speak dutch with my Surinam friends just 
because 400 years ago the ideas of how we should conduct ourselves were 
different.


That is just counterproductive.

Regards,
Maarten

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


Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-05 Thread Maarten Deen

On 2020-01-05 23:25, Tomek wrote:


EN (automatic translation)
I plan to remove the "name" and "wikipedia" tags from places that are
not associated with a specific nation or language:
* continents
* north and south poles
* seas and bays, but exceptionally leaving the "name" tag for seas
with a maximum of two (or three) languages of neighboring countries,
so for example "Белое море" will not change.
The purpose of this edition is to make the OSM map more neutral and
not humiliate people from any country. There is no reason for the


Humiliation is your own feeling. I am not British or American and I am 
not humiliated (or have any negative feelings) when I see such a tag.


Can you explain also what this fixes? If any rendering engine wants to 
render a name and the name tag is not present, it will want to revert to 
another name. That may be name:en. That probably will not be to your 
liking, so will you then also remove the name:en tag?



Baltic Sea to be the "Baltic Sea" or for South America to be "South
America" - this is an example of English imperialism.


This "imperialism" idea of yours is just your idea. It is not something 
that is widely felt.



Any data will not be lost - programs will be able to extract the
desired name from the tags name:en, name:pl, etc., Wikipedia links
will be available via Wikidata.
Please support (vote) my proposal or write a reason why not.


I vote against it, if not only because your stance on this is flawed, 
but also because this might remove correct and valuable information.


Regards,
Maarten

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


Re: [OSM-talk] Relevance of the “name” tag in places where there is no obvious associated language

2019-12-06 Thread Maarten Deen

On 2019-12-06 16:58, Andy Townsend wrote:

On 06/12/2019 15:10, Tomek wrote:


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

W dniu 19-12-06 o 16:08, Tomek pisze:


EN
Is this change acceptable and can I continue?

https://www.openstreetmap.org/changeset/78060265


I don't think this is the best solution


I personally am not a fan of using 8 different names in one name tag
(though some countries that have multiple equal languages do favour
that nationally).   The example here "Baltijas jūra / Baltijos jūra
/ Itämeri / Läänemeri / Morze Bałtyckie / Östersjön /
Østersøen / Ostsee / Балтийское море" seems a bit
clumsy.


I agree with that. It does not solve anything.


Is there an international language used within shipping worldwide?
Perhaps that would be a better option than this.


English.
And in aviation. English.

All examples of the nasty English Imperialist Agressor who wants to 
impose their language on other nations.

Or something like that.

Regards,
Maarten

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


Re: [OSM-talk] Relevance of the “name” tag in places where there is no obvious associated language

2019-12-06 Thread Maarten Deen

On 2019-12-06 14:11, Martin Constantino–Bodin wrote:


Removing the name tag does not solve any problem. The renderer for
the map (or any program that needs to display the name tag) needs to
make a decision which tag to display. If the name tag is not present
it will have to fall back to another one.
In cases where you are running a program on your computer, this
decision might be easy: the language setting of your computer (like
JOSM does). In cases where you make something for a general
audience, that decision will not be so easy. Then you will get into
this discussion about "what language is used most" or "we don't feel
comfortable having an in our eyes non-neutral language pushed up to
us".


I agree that it does not entirely solve the problem. It however
partially solves it: in most contexts, there is a default language
defined. Be it the language of the computer (as you said for JOSM), of
the browser (and, if we look at the HTTP_ACCEPT header, there might
even be more than one!), or some rendering options. If one is printing
a map, there is generally a context around (the language of the book,
or the place—which is usually the same than the computer’s on
which the map is being generated).

Maybe I’ve misunderstood have you mean by “general audience”
here. I would greatly appreciate example where there is no available
default language indirectly provided by the user (’s system) or
context.


You understand correctly. And yes, you can guess a users language from 
either http headers or geolocation or even a cookie. But the issue there 
currently is, is that there is one Mapnik map with the captions rendered 
in the tiles. To do something about that you would need to make a 
different caption layer and present the one you think is right for the 
user viewing the map as an overlay over a non-captioned Mapnik map.
Or you have to make different Mapnik styles for different languages and 
present them also based on those criterea.
Or, as I suggested before: make your own map. The german community has 
one with a different style and lots of placed rendered in German and 
English.


A problem with that is that it takes much more time and storage to make 
those tiles.
I know google does something like it but does it IMHO in a bad way 
because for me it translates every place into a Dutch name, giving rise 
to oddities as Ariën-aan-de-Leie. So if you want to go that way, expect 
it to be less than trivial.



The problem arises out of one of the general OSM principles: use the
name that is verifiable on the ground. This does not work well for
oceans or any international body. No ocean has a sign affixed to it
with its name (well, there might be signposts in different countries
pointing to it).


This is a great point. To me, it seems to point to removing the
“name” tag on such places: this information doesn’t correspond
to anything “real” (but the “name:en” does). And I don’t
even mind if some careless renderers just use “name:en” as a
default is the tag “name” is absent: it’s something that should
be parametric, but a renderer might just have be designed specifically
for English, so whatever.


And I would be violently against removing name tags for such places. 
Oleksiy Muzalyev makes a great point why you should not remove name tags 
from places. It makes them unfindable. You can not find something which 
is not in the OSM database. Having them rendered in an unwanted language 
seems to me to be much more desirable than not being able to find them 
at all.


Regards,
Maarten

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


Re: [OSM-talk] Relevance of the “name” tag in places where there is no obvious associated language

2019-12-06 Thread Maarten Deen

On 2019-12-06 11:46, Martin Constantino–Bodin wrote:


 Some context first.  So there has been this changeset that triggered
some discussions: https://www.openstreetmap.org/changeset/77845837
Changeset comments in not a great place for discussion, so I suggest
that we continue here.  (Thanks @SomeoneElse for the link! ☺) First,



The issue comes in places where there is not a particular language,
like oceans, most seas, or places like Antartica.  In most of these
places, the “name” tag is actually using the English name.

The issue is that English, despite being a de facto internal language,
is felt by some communities as a non-neutral choice, given all the
inequalities it yields among people in the world, given its
complexity, etc.  The Esperanto community is particularly criticising
the choice of the English language as an international language.


IMHO that is more a "he says, she says" argument than anything valid. To 
me it comes more across that a small community wants to push its own 
agenda.
That may be unfair because I don't know how big the Esperanto community 
is, so it is IMHO.



The question I would like to ask is about the relevance of having a
“name” tag in places where there is no default language—knowing
that all the “name:en”, “name:eo”, etc. are already there.  I
can imagine that some renderers might expect to always be a tag
“name”, and I wonder how fixable this is (especially in the cases
where there is a localised name).  If you have any argumented pointer
about this, I would be interested.


Removing the name tag does not solve any problem. The renderer for the 
map (or any program that needs to display the name tag) needs to make a 
decision which tag to display. If the name tag is not present it will 
have to fall back to another one.
In cases where you are running a program on your computer, this decision 
might be easy: the language setting of your computer (like JOSM does). 
In cases where you make something for a general audience, that decision 
will not be so easy. Then you will get into this discussion about "what 
language is used most" or "we don't feel comfortable having an in our 
eyes non-neutral language pushed up to us".


I am biased. I don't know Esperanto. Therefore I would be against 
rendering everything that is not nation-specific in Esperanto.



As far as I know, the wiki doesn’t state anything about English
being the default language for the name tag:
https://wiki.openstreetmap.org/wiki/Names  It thus doesn’t feel like
this question has already been discussed.  However, I never
participated in the main OSM mailing list and thus missed any such
discussions if they already took place.  If so, please give me an
argumented link.


The problem arises out of one of the general OSM principles: use the 
name that is verifiable on the ground. This does not work well for 
oceans or any international body. No ocean has a sign affixed to it with 
its name (well, there might be signposts in different countries pointing 
to it).


So there is no real solution to it. Removing the name tag does not solve 
the problem because a renderer might choose to display name:en.
Changing the name tag to Esperanto does not solve the problem and doing 
that on a global scale I would also see as vandalism. Because why 
Esperanto? Is there a general consensus for that? That is how we operate 
on OSM.


Maybe the esperanto community can solve this by making their own Mapnik 
tiles and using their own www.openstreetmap.eo domain or using 
eo.openstreetmap.org. If they (or anyone else) want to look at the map 
with international names in Esperanto than it is there to use.
I for one would welcome something like that with all captions in latin 
script (like the public transport map, but in full Mapnik style).


Regards,
Maarten

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


Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects

2019-12-06 Thread Maarten Deen

On 2019-12-06 09:55, Martin Koppenhoefer wrote:

Am Fr., 6. Dez. 2019 um 08:08 Uhr schrieb Maarten Deen
:


On 2019-12-05 22:12, Tomek wrote:




Still, it is a Good Idea to have one standard (language) to
communicate
or define things, like everything meant for an international public
in
the wiki is English and the tag system is English.


you should argue why it is a good idea to have _one_ standard language
in the project. IMHO it excludes many billions of people from


Depens on what you use it for. I'm sure you're not arguing for having 
tag names in chinese. These are all in (UK) English. The same goes for 
the majority of the wiki pages geared towards the basis of this project. 
Sure, there are translations (and that is good), but the English page is 
usually the guideline.
I see nothing bad in that. Yes, it implies that you need to be 
relatively proficient in English to be able to contribute there, but 
what is the alternative? Going to Esperanto or Chinese will put more 
people off the project than it will attract.


Why is this list called OSM-talk and not OSM-talk-gb? Because it is the 
main list. And we speak english here.



for other places:
Suggestion 4a: remove the label "wikipedia" and leave only

"wikidata",

I agree that it is strange to have (e.g. for the Caspian Sea
multipolygon 3987743) wikipedia=en:Caspian Sea when it is not in
England. Is there a reason for that other than historic? Since there
is
also a wikidata link.


I am strongly opposing the idea of removing wikipedia article links
when there are wikidata feature links. The former are human readable
and mostly (?) the original data that the mapper added, the latter are
often automatically derived (from wikipedia article references), worse
verified, link to a less mature project (a wikidata entity to which I
link today may change its nature significantly until tomorrow), are
not human readable and a typo in just one digit makes them completely
worseless, and there is no 1:1 relation of wikipedia articles and
wikidata objects (this is btw. a serious problem which I do not know
why the wikidata community doesn't address, they seem to assume that
there is just one wikipedia article for one wikidata object and vice
versa).


I'm not so active in the wikidata project to have seen these problems. I 
was looking at the Caspian Sea and saw a wikidata link that has 175 
wikipedia links in it. Yes, you can get that too by opening the English 
wikipedia page page, but that again does nothing against the "English 
dominance" argument.
But then again, the wikidata page also does not do that because it is in 
English only.



Please also note that "wikipedia:en" is not about "England", it is the


It is not about England, it is about the perceived English dominance of 
the project.



knowledge of the world collected in the English language (btw. it is
the wikipedia version with most articles). With all


Precisely. So I found your comment "you should argue why it is a good 
idea to have _one_ standard language in the project." a bit odd. Why is 
that English knowledge better than the wikipedia:cn page? Just because 
it is English?
The fact of the matter is that a brit started the project, that alone 
gives a lot of credibility to using English as native language for the 
project. Above and beyond that, English just is the main language, at 
least of the western world. And that has nothing to do with wanting to 
rule the world. I'm not British or American and I'm perfectly ok with 
this situation.


And lets face it, if a Chinese person had started this, most of us 
probably would not have know about it because it was all in Chinese.


Regards,
Maarten

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


Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects

2019-12-05 Thread Maarten Deen

On 2019-12-05 22:12, Tomek wrote:


EN:
In what language should the names of interstate objects be: seas /
bays, continents, oceans, poles? They are not currently displayed on
the default map(1), programs (e.g. OsmAnd, iD and JOSM editors) use
the name:LANGUAGE label, so the content of the "name" label is
ideological only, not practical.


I disagree that the name tag is ideological. Maybe you use the wrong 
word and meant theoretical?



Currently they are in English, which cannot be accepted, Great Britain
and the USA are not masters of the whole world.


As I don't know where the nodes are I can not check if your comment is 
correct, but while I understand your problem, this seems more like a 
frustrated rant.



Suggestion 1: for smaller seas, I suggest adding names in all official
/ main languages ​​of adjacent countries, so instead of "Black
Sea" there will be:
Karadeniz Marea Neagră Чорне море | Черно море |
Чёрное море | შავი ზღვა


I get nothing displayed at the Black Sea. It is only defined by the 
coastline, there is no (multi)polygon defining its boundaries. Is there 
a node?


The adjacent Caspian sea is displayed as دریاچه خزر which is not the 
complete name tag (Каспийское море / Хәзәр дәнизи / دریاچه خزر) but 
looks to me the name:fa (Farsi).
For me, that is very bad since I can not read Farsi so I don't know what 
is written there. Same applies to Chinese, Japanese, Korean, and a whole 
host of languages that do not use the latin script. So your described 
problem does not limit itself to non-English speakers, it also applies 
to the same Brits and US Americans that you rant about being the masters 
of the world.

IMHO Openstreetmap does try to be politically and nation independent.

Still, it is a Good Idea to have one standard (language) to communicate 
or define things, like everything meant for an international public in 
the wiki is English and the tag system is English.



For larger seas (with more neighboring countries, so the name would
exceed the 255 character limit in OSM) and for continents, oceans and
poles you need to come up with something else:

Suggestion 2a: remove the "name" tag completely


It should be looked at if this is a viable option. JOSM already uses the 
localized names to display names in JOSM itself. E.g. the afore 
mentioned multipolygon for the Caspian Sea displays as "multipolygon 
("Caspian Sea", 80 members, incomplete) [id: 3.987.743]" for me. It does 
not show the name tag.
For me that is usually the best option. It would be great if this could 
be extended to the main map, but for that you would probably need to 
make a different captions overlay.



Suggestion 2b: use the name in a neutral language, i.e. planned or
extinct: Lingvo Internacia Esperanto (EO), Interlingua (IA), Ido (IO),
Latin (LA), I don't know Latin, so I would need help.


Does that solve the non-latin alphabets? I don't know if their 
understanding of the latin alphabet is as bad as my understanding of the 
non-latin alphabets.



How can I resolve a problem with the "wikipedia" label?


There is a wikidata label, but that only defines what it is, not what 
name should be rendered.



Suggestion 3: for a place with fewer names, I suggest using several
labels:
wikipedia: ru = Чёрное море + wikipedia: ro = Marea Neagră,


And which of those will be on the map?


for other places:
Suggestion 4a: remove the label "wikipedia" and leave only "wikidata",


I agree that it is strange to have (e.g. for the Caspian Sea 
multipolygon 3987743) wikipedia=en:Caspian Sea when it is not in 
England. Is there a reason for that other than historic? Since there is 
also a wikidata link.



Suggestion 4b: add links in a neutral language: wikipedia=ia: Mar
Nigre


Why is Anguilla a neutral language? Mar Nigre looks French to me, why is 
that a neutral language?
Should it be Esperanto? Why would that be a neutral language since it is 
written in latin alphabet? Also Esperanto to me seems more like a 
western language than an eastern/asian language.



Suggestion 4c: add more links, but in which languages?

1. unless mapped as relation with other tags (natural = bay/water),
but the woodpecker user deleted the relation for the Black Sea:
https://www.openstreetmap.org/relation/7160849/history


It is better to link to the changeset, because that gives a comment and 
can be loaded easily:

https://www.openstreetmap.org/changeset/77922074

I'm not sure if I agree with the reason of deletion. Currently there is 
no name displayed and finding the node is difficult.


Your problem is a universal problem on any platform that spans the globe 
and IMHO there is no one answer to it. For one I would love to see all 
name tags rendered in something I can at least read (i.e. latin script). 
For that I frequently have to use the transport map layer so I can at 
least read what city in China (for example) I'm looking at.


Regards,
Maarten


___
talk mailing list

Re: [OSM-talk] OSM very old data

2019-11-29 Thread Maarten Deen

On 2019-11-29 10:43, Tom Ka wrote:


https://kasparkovi.net/osm/
(top letf selection for older maps)


No answer to your questions, but cool to see the map grow like that!

Maarten

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


Re: [OSM-talk] Tesla using OSM without attribution?

2019-11-12 Thread Maarten Deen

I extend that irony to taking the car to the gym.
But I guess as a Dutchman I have different ideas on how to transport 
myself than the Americans do.


But suppose the apocalypse is upon us and the floor is lava, wouldn't it 
be nice if your car came to the rescue? "KITT, buddy, come over here".
Yes, I am expecting that as the next feature, that I can call my car by 
its name and that it will come to me.

Brave new world.

Regards,
Maarten

On 2019-11-12 14:32, Dave F via talk wrote:

I have to laugh at the irony of not only driving to a gym, but then
being too lazy to even walk from the entrance back to the car.

DaveF

On 12/11/2019 10:11, MARLIN LUKE wrote:


I've recently come across the information that Tesla might be using
OSM, at least for it's "smart summon" feature. The point of the
feature is to make the car self drive to you from it's parking lot.

Tesla Motor Club Forum users have noticed that the "smart summon"
works better when they correct OSM data in the parking lots around
them [1].
Tesla Motor Club put up a small article that sums it up [2] but in
the forum there is additional information that might be valuable.
There, a user mention sytem logs about Vahlalla: a lib that
apparently relies on OSM [3].

I don't own one so I cannot check if there is any attribution,
however it looks like there is none.

I'm also unsure what to do with that information if it is true,
that's why I'm opening up this thread.

[1]


https://teslamotorsclub.com/tmc/threads/tesla-owners-can-edit-maps-to-improve-summon-routes.172027/

[2]


https://teslamotorsclub.com/blog/2019/11/04/tesla-owners-can-edit-maps-to-improve-summon-routes/

[3] https://github.com/valhalla/valhalla

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

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


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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-05 Thread Maarten Deen

On 2019-11-05 10:58, Simon Poole wrote:
The clause is mainly a consequence of the relevant GDPR rules and at 
the

time (not sure why we are having this discussion after the fact) we
spent a lot of time investigating what potential routes there could be
to working around this, but nobody came up with a workable solution.


Surely there could have been made a distinction between viewing the 
map/wiki/whatever and registering an account?
Is there anyone who believes that we should block children from looking 
at the map at www.openstreetmap.org? Or that that is required from a 
legal standpoint?


Regards,
Maarten


Am 05.11.2019 um 10:40 schrieb Maarten Deen:

On 2019-11-05 10:12, Mateusz Konieczny wrote:

4 Nov 2019, 12:53 by md...@xs4all.nl:


In any case, I see that the "You must be 13 years or older to use
the Services." is still there.

Really? Someone under 13 can not look at the OSM map? I'm sorry, but
that is completely laughable. And not enforcable at all.


It is probably necessary for legal reasons, such requirement is
typical in TOUs.

Mostly result of COPPA[1] and similar laws. Extreme requirements on
providing
service to children younger than 13 makes it is easier to ban all
children younger than 13
from service than comply with them.

Especially in cases where children are not very likely to contribute


"Use" in this case is also viewing the website. There is no account
needed for that and if you want to block this you would need to do age
verification which is a lot more intrusive than not putting this
clause in your ToU at all. If people think OSM should be doing this,
they effectively say that children should not use the internet. That
may be your choice, but it is just that: a choice. In no way a legal
requirement.

COPPA does not seem to apply since OSM is not directed to children,
let alone in commercial ventures. The only possible connection would
be when children register since you would store information about
them. That might be a sensible reason to block children from
registering (I can also see that they probably would not have a
significant positive contribution to the data), but again, at the
moment any use of OSM by children is blocked.

Either no thought went into that, or it was thought that throwing a
wide net would be better "to comply" than no net at all. The same
thing I argue against with the "lots" comment that started this.
Better to claim that lots of the things you might do to keep your
privacy are not allowed according to the ToU than to make clear which
things exactly are not allowed.
It looks more like FUD to me at the moment.

Regards,
Maarten

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



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


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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-05 Thread Maarten Deen

On 2019-11-05 10:12, Mateusz Konieczny wrote:

4 Nov 2019, 12:53 by md...@xs4all.nl:


In any case, I see that the "You must be 13 years or older to use
the Services." is still there.

Really? Someone under 13 can not look at the OSM map? I'm sorry, but
that is completely laughable. And not enforcable at all.


It is probably necessary for legal reasons, such requirement is
typical in TOUs.

Mostly result of COPPA[1] and similar laws. Extreme requirements on
providing
service to children younger than 13 makes it is easier to ban all
children younger than 13
from service than comply with them.

Especially in cases where children are not very likely to contribute


"Use" in this case is also viewing the website. There is no account 
needed for that and if you want to block this you would need to do age 
verification which is a lot more intrusive than not putting this clause 
in your ToU at all. If people think OSM should be doing this, they 
effectively say that children should not use the internet. That may be 
your choice, but it is just that: a choice. In no way a legal 
requirement.


COPPA does not seem to apply since OSM is not directed to children, let 
alone in commercial ventures. The only possible connection would be when 
children register since you would store information about them. That 
might be a sensible reason to block children from registering (I can 
also see that they probably would not have a significant positive 
contribution to the data), but again, at the moment any use of OSM by 
children is blocked.


Either no thought went into that, or it was thought that throwing a wide 
net would be better "to comply" than no net at all. The same thing I 
argue against with the "lots" comment that started this. Better to claim 
that lots of the things you might do to keep your privacy are not 
allowed according to the ToU than to make clear which things exactly are 
not allowed.

It looks more like FUD to me at the moment.

Regards,
Maarten

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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-04 Thread Maarten Deen

On 2019-11-04 12:40, Andy Mabbett wrote:

On Mon, 4 Nov 2019 at 11:17, Simon Poole  wrote:


Am 04.11.2019 um 10:03 schrieb Maarten Deen:



> the ToU says "You represent and warrant that the information you
> provide to OSMF upon registration and, at all other times, will be
> true, accurate, current, and complete"



https://wiki.osmfoundation.org/wiki/Terms_of_Use#II._Privacy requires
you to keep your contact information (which is currently your e-mail
address) current. This is not really new as it was implied by doing 
away

with anonymous edits in 2007.


Good luck enforcing that for someone who hasn't edited for a decade or 
more.


Which perfectly fits the editing habits of someone who uses throw-away 
email adresses on a regular basis...


Regards,
Maarten

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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-04 Thread Maarten Deen

On 2019-11-04 12:17, Simon Poole wrote:

Am 04.11.2019 um 10:03 schrieb Maarten Deen:

On 2019-11-04 09:28, Simon Poole wrote:

Am 03.11.2019 um 23:08 schrieb Martin Koppenhoefer:

...
it depends from whom you hide, but generally you should not use a
traceable email account if you want to remain anonymous. Using
Google would seem like a total no-go (they are even reserving the
right to read your emails). Use a live distro like tails (tor
browser, spoofs browser a system details, etc. ), do not connect
from your home or someone else’s home or any other places that you
are related to, do not use a third party login but create a new
account for every edit you make and use throw away email addresses
for signup. Use generic user names and email addresses created by a
random string generator, only use the most common tools like iD and
maybe josm, do not use rarely used tags, avoid changeset comments
and other free text fields like description and note.


Note, lots of the above would be violations of our ToU, and outside 
of

that, neither desirable nor a good idea.


Lots? Care to elaborate on that? Where are the ToU, is it
<https://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft>
(to which I can have some comments too)?

..


https://wiki.osmfoundation.org/wiki/Terms_of_Use  and linked to from 
the

sign up page, and from the map page. There where multiple opportunity
last year to comment on the draft (which has nothing to do with the old
wiki page you linked too), which you seemed to have not used, even
though it was widely announced.


I have not used no. I generally don't concern myself with such things 
because my views are generally not the views of people making these 
policies (and are therefore usually ignored).


I was searching for it on the wiki and that was the only one I found. I 
thought it was a bit stale since it wasn't touched since 2009 and no 
discussion followed there.
In any case, I see that the "You must be 13 years or older to use the 
Services." is still there.
Really? Someone under 13 can not look at the OSM map? I'm sorry, but 
that is completely laughable. And not enforcable at all. Maybe you 
should put a PG-13 sign on the map ;)
Also: 16 and 17 year old are also still a minor, even in the UK, and 
they are not blocked from anything in the ToU?



In any case, if the link I posted are the ToU, I don't see any of
those points being a violation of the ToU. In the case of the account,
where the ToU says "You represent and warrant that the information you
provide to OSMF upon registration and, at all other times, will be
true, accurate, current, and complete" it is an empty point since
there is no verifiable information I _have_ to enter into my account.
Just a screen name (not my legal name) and an email address.


https://wiki.osmfoundation.org/wiki/Terms_of_Use#II._Privacy requires
you to keep your contact information (which is currently your e-mail
address) current. This is not really new as it was implied by doing 
away

with anonymous edits in 2007.


That is in no way a strange request. Yes, it more or less precludes 
throwaway email adresses (you are at least required to respond I guess) 
but it does not preclude using an anonymous email adress.



Further items like my location and a profile description are optional.


To be clear certain risk reduction measures are completely OK and we
outline these in the privacy policy, what is not OK is anything that
amounts to de facto making the edits anonymous to the OSMF.


It was more your assertion that "lots" of the items given would be 
violations of the ToU where I come to 3 out of 11 that might be.
I still don't see where the lots comes from, you didn't care to 
elaborate on that.


Regards,
Maarten

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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-04 Thread Maarten Deen

On 2019-11-04 09:28, Simon Poole wrote:

Am 03.11.2019 um 23:08 schrieb Martin Koppenhoefer:

...
it depends from whom you hide, but generally you should not use a 
traceable email account if you want to remain anonymous. Using Google 
would seem like a total no-go (they are even reserving the right to 
read your emails). Use a live distro like tails (tor browser, spoofs 
browser a system details, etc. ), do not connect from your home or 
someone else’s home or any other places that you are related to, do 
not use a third party login but create a new account for every edit 
you make and use throw away email addresses for signup. Use generic 
user names and email addresses created by a random string generator, 
only use the most common tools like iD and maybe josm, do not use 
rarely used tags, avoid changeset comments and other free text fields 
like description and note.


Note, lots of the above would be violations of our ToU, and outside of
that, neither desirable nor a good idea.


Lots? Care to elaborate on that? Where are the ToU, is it 
 
(to which I can have some comments too)?


To break down:
1) not use a traceable email account
2) not use Google
3) Use a live distro
4) do not connect from your home or someone else’s home or any other 
places that you are related to
5) do not use a third party login but create a new account for every 
edit you make

6) use throw away email addresses for signup
7) Use generic user names and email addresses created by a random string 
generator,

8) only use the most common tools like iD and maybe josm
9) do not use rarely used tags
10) avoid changeset comments
11) and other free text fields like description and note.

1-4, 8, 9 and 11 surely can not be blocked by the ToU
5-7 maybe, but 7 is not enforcable anyway (well, you can see true random 
but can not see chosen random)

10 is chosen to be bad practice

In any case, if the link I posted are the ToU, I don't see any of those 
points being a violation of the ToU. In the case of the account, where 
the ToU says "You represent and warrant that the information you provide 
to OSMF upon registration and, at all other times, will be true, 
accurate, current, and complete" it is an empty point since there is no 
verifiable information I _have_ to enter into my account. Just a screen 
name (not my legal name) and an email address.

Further items like my location and a profile description are optional.

Regards,
Maarten

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


Re: [OSM-talk] Maintaining privacy as a casual mapper

2019-11-03 Thread Maarten Deen

On 2019-11-03 11:42, Philippe Latulippe wrote:

Hello everyone!

I like to improve OSM casually, making small fixes as I use the map in
my day-to-day life. However, doing so without any precautions would
reveal a great deal of information about where I've been, since my
edits cover exactly the places where I'm active. A look at my edit
history would reveal where I live, where I work, where I've traveled.
If last night I had added a detailed POI of a restaurant and nothing
else, one could correctly assume that I was at that restaurant
recently.

I've managed to protect my privacy somewhat by creating one account
for every neighbourhood I want to map. This is time consuming and
error prone, and it's held me back from making improvements to the
map.

Are there better ways to maintain some privacy while editing the map?
Are there some tools? Or is there a way to make edits in a way that
doesn't reveal my username to regular users?


What do you use your OSM username for? Is there any reason not to create 
an anonymous username like anon65498?


I mean, sure your mailadres suggests your name is Philippe Latulippe and 
I can find some people with that name on the internet, but how do I know 
that is your real name and not an alias?


Regards,
Maarten

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


Re: [OSM-talk] EuroVelo routes are out of date

2019-10-03 Thread Maarten Deen

On 2019-10-03 10:55, Richard Fairhurst wrote:

Maarten Deen wrote:

Is it an idea to create some kind of ticketing system for this?


I think we already have this:

- create notes on osm.org, including the word "eurovelo"
- search for "eurovelo" on https://ent8r.github.io/NotesReview/


Great, if only it was used like that a bit more...

Regards,
Maarten

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


Re: [OSM-talk] EuroVelo routes are out of date

2019-10-03 Thread Maarten Deen

On 2019-10-03 10:27, Richard Fairhurst wrote:

EuroVelo routes are not in a great state in OSM. Many of them appear
to have been armchaired years ago when routes were "in development",
and not updated since to reflect the correct route.

A handful of examples:



…and there are lots more.


I'm sure I'm not saying anything new when I say that this is a general 
problem with routes in OSM.


Is it an idea to create some kind of ticketing system for this? Maybe 
put this all in Trac? Because someone who notices this may not always be 
someone who can check it. And you give a few examples now, but leave out 
the lots more that may be close to where other people can check.


Regards,
Maarten

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


Re: [OSM-talk] Abuse of natural=cliff tag

2019-09-11 Thread Maarten Deen

On 2019-09-12 06:30, Mark Wagner wrote:

On Wed, 11 Sep 2019 20:54:17 +0200
Vladimir Vyskocil  wrote:


> On 11 Sep 2019, at 20:20, Mark Wagner  wrote:
>
>
> On Wed, 11 Sep 2019 15:33:05 +0200
> Vladimir Vyskocil  wrote:
>
>> A even crazier area regarding the abuse of the cliff tag !
>>
>> https://www.openstreetmap.org/#map=15/50.9610/14.0724
>> 
>
> Doesn't look crazy to me.  From what I saw on the map, I expected
> there to be rock formations of the sort you'd find in south Utah.
> Switching to aerial imagery, I saw pretty much that, just with more
> trees.

https://www.openstreetmap.org/edit#map=20/50.96391/14.06867
 really ?


Really.  The lack of leaves-off imagery means I can't see what's under
the trees, but the shadows in some of the imagery options are not
inconsistent with the sort of stepped cliff it appears to be mapping.


Some imagery of the area: 



Not that I'm defending the tagging, it seems excessive to me, but the 
area is filled with cliffs.


Regards,
Maarten

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


Re: [OSM-talk] add notes to personal profile

2019-07-18 Thread Maarten Deen

On 2019-07-18 10:18, Warin wrote:

On 18/07/19 17:57, Maarten Deen wrote:

On 2019-07-18 09:44, Warin wrote:

On 18/07/19 16:58, Maarten Deen wrote:

On 2019-07-17 18:03, Philip Barnes wrote:

On Wed, 2019-07-17 at 17:40 +0200, Martin Trautmann wrote:




Is there any chance to connect the notes database with the user's
profile?

Notes that you create, either through osm.org or OSMand can be 
found on

your profile under My Notes.


In OSMAnd?


Similar to maps me etc, a phone render that has some editing 
capabilities.


In a similar fashion it could be said
"Notes that you create, either through osm.org, iD, JOSM or OSMand 
can

be found on
your profile under My Notes." I am certain there are other ways of
entering data into osm..


My question was more pointed to where you can find those notes. 
Whether the "My Notes" function is something in OSMAnd or in OSM.

I can't find it in OSM. It's not in my profile.


When you add stuff to OSM either by JOSM,id or OSMand ... it all goes
into the OSM date base. OK?

To find your notes that are in the OSM data base .. go to your OSM
user profile        https://www.openstreetmap.org/user/ where 
is your OSM user name.

There you will find across the upper part of the screen some blue 
writing


My Edits  My Notes My Traces My Diary My Comments My Settings

Click on "My Notes"   I think that is enough information?


Hmm. I must have been blind. I probably was blind to this link because 
there was no number behind it. OSM shows how much edits, how much 
traces, how much diary entries I made, but not how much notes.


And of course it was in Dutch so it is not called My Notes :/

Maarten

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


Re: [OSM-talk] add notes to personal profile

2019-07-18 Thread Maarten Deen

On 2019-07-18 09:44, Warin wrote:

On 18/07/19 16:58, Maarten Deen wrote:

On 2019-07-17 18:03, Philip Barnes wrote:

On Wed, 2019-07-17 at 17:40 +0200, Martin Trautmann wrote:




Is there any chance to connect the notes database with the user's
profile?

Notes that you create, either through osm.org or OSMand can be found 
on

your profile under My Notes.


In OSMAnd?


Similar to maps me etc, a phone render that has some editing 
capabilities.


In a similar fashion it could be said
"Notes that you create, either through osm.org, iD, JOSM or OSMand can
be found on
your profile under My Notes." I am certain there are other ways of
entering data into osm..


My question was more pointed to where you can find those notes. Whether 
the "My Notes" function is something in OSMAnd or in OSM.

I can't find it in OSM. It's not in my profile.

Maarten

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


Re: [OSM-talk] add notes to personal profile

2019-07-18 Thread Maarten Deen

On 2019-07-17 18:03, Philip Barnes wrote:

On Wed, 2019-07-17 at 17:40 +0200, Martin Trautmann wrote:

Hi all,

I recently uploaded some notes from osmand+ to openstreetmap, but did
not see them first.

I now learned how to activate the notes layer both for openstreetmap
and
its editor.

But I would prefer that notes would be added to my personal profile
in
order to find and edit them.

Is there any chance to connect the notes database with the user's
profile?


Notes that you create, either through osm.org or OSMand can be found on
your profile under My Notes.

HTH Phil (trigpoint)


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


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


Re: [OSM-talk] add notes to personal profile

2019-07-18 Thread Maarten Deen

On 2019-07-17 18:03, Philip Barnes wrote:

On Wed, 2019-07-17 at 17:40 +0200, Martin Trautmann wrote:




Is there any chance to connect the notes database with the user's
profile?


Notes that you create, either through osm.org or OSMand can be found on
your profile under My Notes.


In OSMAnd?

I can't find that on the OSM website?

Maarten

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


Re: [OSM-talk] handling street names in speech

2019-07-17 Thread Maarten Deen
On Wed, Jul 17, 2019 at 12:58 AM Andrew Errington  
wrote:



I think this is a rendering issue (i.e. rendering speech instead of
graphics) and as such does not belong in OSM.

The work to convert an arbitrary string into speech belongs in the
TTS engine.

If we start putting IPA strings in OSM then we will start getting
arguments about the "correct" pronunciation. At the very least it is
tagging for the renderer, which we should avoid.


And if not, then you're at the will of the TTS engine. There are words 
that are pronounced differently depending on their meaning. Some example 
from the English language, I'm sure other languages have examples too:

a bow - to bow (second sounds more like baw)
he does things - the does do things (short o, long o)
A minute part of a minute
wind (is blowing) - wind (the clock)

And then we haven't even touched the problem on which syllable to put 
emphasis.


All these things make it impossible for a TTS engine to know what 
pronunciation is correct, except when you lay it down for each word. We 
had a new operator for the public transport in my neighborhood and they 
used a TTS engine to generate the stop information. It was just 
horrible. Incorrect pronunciation, incorrect emphasis.


The OsmAND TTS also does funny things, there is a John F. Kennedystreet 
in my town. The TTS pauses at the dot. Obviously it thinks the sentence 
ends there. But it doesn't. It's just an abbreviation. And no, this is 
not an abbreviation like St. or Ave. that you would write out fully. The 
street name is not John Fitzgerald Kennedystreet.


IMHO an IPA string would be a welcome and usefull addition to OSM.
Could you also not use it for transliterations?

Regards,
Maarten

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


Re: [OSM-talk] Documenting controversial iD decisions

2019-05-28 Thread Maarten Deen
IMHO the strategy for adding roads also should be on this list. The 
optionlist to add accessrights for "all, foot, motorvehicles, bicycle, 
horse" resulting in a foot=yes, motorvehicle=yes, bicycle=yes, horse=yes 
on all roads is creating redundant tagging.


Maarten

On 2019-05-29 06:29, Andrew Harvey wrote:

I'm not sure if this should be added, but at the time how iD decided
to add presets for lifeguards facilities was controversial.

We used to have documented on the wiki and in use:
emergency=lifeguard_place
emergency=lifeguard_base
emergency=lifeguard_tower

emergency=lifeguard_platform

Which each were to be used to map different kinds of lifeguard
infrastructure on the ground.

Prompted by a request at
https://github.com/openstreetmap/iD/issues/4918 it was then decided by
Bryan at
https://lists.openstreetmap.org/pipermail/tagging/2018-June/037080.html
that "We have too many tags for different kinds of lifeguards.  This
is too confusing. I don’t want to have to show all these choices to
iD users."

And it was decided by the iD maintainers to change the existing used
and documented tag emergency=lifeguard_place to emergency=lifeguard,
and only support that tag and none of the other types of lifeguard
facilities.

On Wed, 29 May 2019 at 08:50, Michael Reichert
 wrote:


Hi,

I started documenting controversial decisions by the maintainers of
iD
at https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

Currently, only the highway=footway and the nonsquare=yes issue are
mentioned.

Please feel free to add other issues which have proofed
controversial so
far. Don't forget to summarise the opinion of the maintainer as well
to
aim at least some neutrality as far as it is possible for those
involved
in the disputes. Please add links to relevant discussions as well.

Best regards

Michael

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

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

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


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


Re: [OSM-talk] problems with differential update?

2019-04-12 Thread Maarten Deen

On 2019-04-12 09:52, Simon Poole wrote:

Am 12.04.2019 um 08:26 schrieb Maarten Deen:


Does the determination in java follow the same rules (or even the same
library) as file(1)? In its manpage it says

file tests each argument in an attempt to classify it. There are
three sets of tests, performed in this order: filesystem tests, magic
tests, and language tests. The first test that succeeds causes the
file type to be printed.


Is there any similarity in the first bytes of the zipped file?


This would be a valid question except: I hardwired the decompression
type to GZip yesterday in a test version of osmosis and still got the
error and as said a test program using the same methods decompresses 
the

file just fine.


That is interesting. I don't know how the unzipping is done in osmosis, 
but if it is still a java call (now hardwired to use gzip, I assume the 
executable, not a built in library), could it not be that java still 
tries to figure out what kind of file it is and fails because of that?


Regards,
Maarten

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


Re: [OSM-talk] problems with differential update?

2019-04-12 Thread Maarten Deen

On 2019-04-11 22:40, mmd wrote:

Am 11.04.19 um 21:33 schrieb Frederik Ramm:

Hi,

On 4/11/19 21:26, Roland Olbricht wrote:
Could it have been that the file triggered an arcane bug in a gz 
library

from the Java universe?


Yes, that's exactly the problem - these files decompress fine with 
gzip,

just not with Java.



Nothing really new here. That's exactly the same thing which happened
two months ago:
https://lists.openstreetmap.org/pipermail/talk/2019-February/082057.html


Does the determination in java follow the same rules (or even the same 
library) as file(1)? In its manpage it says
file tests each argument in an attempt to classify it. There are three 
sets of tests, performed in this order: filesystem tests, magic tests, 
and language tests. The first test that succeeds causes the file type 
to be printed.


Is there any similarity in the first bytes of the zipped file?

Regards,
Maarten

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


Re: [OSM-talk] 140 000 shops of unspecified type

2019-03-15 Thread Maarten Deen

On 2019-03-15 11:08, Mateusz Konieczny wrote:

About 4% of all tagged shops have shop=yes as its primary tag what is

not properly providing information about shop type.

It would nice to reduce it a bit (at least stop growing share of
shop=* tags).



how to find it?

JOSM validator since latest released version complains about shop=yes
-

just download data and run validator


This would be a perfect job to make a Maproulette task for.

Regards,
Maarten

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


Re: [OSM-talk] Relation #2632934 is "killing" differential update

2019-02-11 Thread Maarten Deen

On 2019-02-11 12:14, Roland Olbricht wrote:

Hi,

the relevant changesets are
65448087 (for version 99, created_by "upload.py v. 1") and
67093992 (for version 106, created_by "Vespucci 12.1.2.0").

I cite the user agents because the data looks like unintentionally
changed that way.
I have left a bug report on Vespucci, see
https://github.com/MarcusWolschon/osmeditor4android/issues/859


I have removed all duplicates from the relation but done nothing to 
check remaining data for correctness. It's only 350 unique members.


Maarten

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


Re: [OSM-talk] Strang (non-)rendering issue

2019-02-04 Thread Maarten Deen

On 2019-02-04 11:52, Hartmut Holzgraefe wrote:

On 04.02.19 11:10, Maarten Deen wrote:


The changes still don't show up. Also in another area [1] I've made
changes (Kirchstraße is not pedestrian and added to memorials) that
don't show up.
Also someone on the dutch mailing list complained about changes not
showing up.
Is the renderer that caters for the Netherlands working ok?



At first try I only got updated tiles partially, ways on the parking
lot from example #1 ended in the middle of the lot, and one part of
Kirchstraße in example #2 was still showing as pedestrian.

After reloading the browser page with CTRL-R everything looked fine
in Firefox.

Chromium was still showing old tiles though for all of Kirchstraße,
even after CTRL-R. Only after a forced reload with SHIFT-CTRL-R
the pedestrian section was gone.

So the issue is not so much with tile rendering, but seems to be
about the different cacheing layers involved ...


My normal browser is Firefox and no amount of reloading works, but sure, 
this could be a caching issue.
I also have Pale Moon and IE and both have not been used to view the 
area before and they both show the old tiles. No amount of zooming in or 
out or reloading helps.
If it is a caching issue, it is upstream from me and I find it very 
strange that tiles would get cached that long (in the case of my edits 
around Drauffelt).


Regards,
Maarten

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


Re: [OSM-talk] Strang (non-)rendering issue

2019-02-04 Thread Maarten Deen

On 2019-01-30 17:45, Tom Hughes wrote:

On 30/01/2019 16:22, Maarten Deen wrote:

Are there different rendering servers for those regions? I know that 
there are different tileservers, but I didn't know the rendering was 
also different. Is that not really inefficient to have two servers 
render the same tiles?


There are currently five render servers.


The changes still don't show up. Also in another area [1] I've made 
changes (Kirchstraße is not pedestrian and added to memorials) that 
don't show up.
Also someone on the dutch mailing list complained about changes not 
showing up.

Is the renderer that caters for the Netherlands working ok?

[1] <https://www.openstreetmap.org/#map=19/50.71609/6.01418>

Regards,
Maarten

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


Re: [OSM-talk-nl] Changeset na een paar dagen nog niet zichtbaar

2019-02-01 Thread Maarten Deen

On 2019-02-01 14:54, Patrick Coenen wrote:

Ieder, ik heb dit nog niet meegemaakt. Een snelle aanpassing van een
nieuw aangelegd fietspad en bijbehorende afsluiting van aangrenzende
straten, maar is door mij in ID gedaan en gecommit. Maar de
wijzigingen zijn na een paar dagen nog steeds niet zichtbaar. Heb ik
iets gemist? Set: #66764935


Ik heb hetzelfde met een changeset. Ik zie hem wel als ik vanuit mijn 
werk verbind (dat gaat via de UK of USA, een van beide), maar vanuit mij 
thuis zie ik hem niet.
Ik had dit op de algemene talk ook al even genoemd en daar kwam Tom 
Hughes met de melding dat er voor verschillende regio's ook 
verschillende render computers zijn.

Lijkt me erg inefficient, maar goed.

Volgens mij zie ik je changeset hier ook. Je hebt het einde van de 
Thermiekstraat in een fietspad veranderd en een fietspad langs de 
Reijmersbekerweg gelegd?


Maarten

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


[OSM-talk] Strang (non-)rendering issue

2019-01-30 Thread Maarten Deen
Yesterday I made some changes around the railway station in Drauffelt: 
https://www.openstreetmap.org/#map=19/50.01668/6.00843
I added some roads in the parking lot and a pick-nick site between the 
Clerve and the Irbich.


This morning at work I checked how it looked and it was rendered. Now 
when I look at home it is not rendered, at any zoom level. Not with 
refreshing, not with using a different browser.


The biggest difference between home and work is that home is connected 
to a dutch provider and work is connected to a UK provider on a US 
IP-address.
Are there different rendering servers for those regions? I know that 
there are different tileservers, but I didn't know the rendering was 
also different. Is that not really inefficient to have two servers 
render the same tiles?


Regards,
Maarten

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


Re: [OSM-talk] Editing road geometry Australia

2019-01-12 Thread Maarten Deen

On 2019-01-11 23:15, Warin wrote:

On 11/01/19 21:45, Markus wrote:

On Fri, 11 Jan 2019 at 07:40, Maarten Deen  wrote:

On 2019-01-11 07:16, Petra Rajka - (p) wrote:



   * -35.3409195, 149.1616891

Ways 77001149 and 77000891 should IMHO not be mapped like that but
mapped with turn:lanes.

+1


-1

I disagree. But then I could be wrong.

In the above (Canberra) example:

Where a solid line exists between the two groups of lanes there is a
'legal barrier' that you cannot legally cross between the two groups of
lanes (2 go right and 2 continues


But solid lines (single and double) used in the sense of "not allowed to 
pass" or "not allowed to change lanes" are used everywhere over the 
whole world.
I'm sure you're not suggesting that this [1] road should be mapped as 
two seperate ways? Then why would we map other roads with no physical 
divider as two seperate ways?


[1] 
<https://www.google.nl/maps/@51.4313146,5.7421874,3a,75y,318.25h,88.15t/data=!3m5!1e1!3m3!1sYKLDgYrrbp4KJZFp1iqXsw!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3DYKLDgYrrbp4KJZFp1iqXsw%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D15.575244%26pitch%3D0%26thumbfov%3D100>



Also using the tag lanes how can the turn restrictions that exist be
tagged, the right 2 must turn right and the left 2 must go straight on 
?


turn:lanes=right|right|straight|straight

Regards,
Maarten

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


Re: [OSM-talk] Editing road geometry Australia

2019-01-11 Thread Maarten Deen
I agree that Markus' solution is more elegant (and I was more looking to 
the offramp itself). I would normally also map it like that but I also 
don't go out of my way to correct situations like that.
The way it is mapped now is more organic, more as you would actually 
drive. As such I don't see it as wrong.


I would not add a turn restriction. For routers it is useless because 
you never get that route anyway.


Regards,
Maarten

On 2019-01-11 13:23, Jem wrote:

I'd map that place like that:

https://wiki.openstreetmap.org/wiki/File:ID_Screen_Shot_from_-32.0914374,_116.0129206.png

I agree. And a supplementary question... would you also add a
no-left-turn restriction from https://osm.org/way/581948344 at
https://osm.org/node/5680879176? I would, and have done in the past.
But to be honest, I'm not sure if a turn like that (having already
passed the slip lane designated for the turn) is legal or not.

On Fri, 11 Jan 2019 at 20:47, Markus 
wrote:


On Fri, 11 Jan 2019 at 07:40, Maarten Deen  wrote:


On 2019-01-11 07:16, Petra Rajka - (p) wrote:



See below two cases where we would simplify the geometry:

  * -32.0914374, 116.0129206


Is seen no big problem in how the roads are layed out there.

Coming from

the motorway there is a clear divider where the offramp connects

to the

Albany Highway.


<https://www.openstreetmap.org/way/596272469> and
<https://www.openstreetmap.org/way/596272466> form a
double-rectangle,
but there isn't such a divider. I'd map that place like that:



https://wiki.openstreetmap.org/wiki/File:ID_Screen_Shot_from_-32.0914374,_116.0129206.png



I have more problems with the tags of the on- and offramp. They

are

mapped as motorway when they should be mapped as motorway_link.

The two

bridges in the on- and offramp are mapped as motorway_link.


+1. I'd also delete the descriptions like Tonkin Highway Southbound
Ramp off to Albany Highway in the name tag unless the ramps are
signed
like that on site.


  * -35.3409195, 149.1616891


Ways 77001149 and 77000891 should IMHO not be mapped like that but
mapped with turn:lanes.


+1

Regards

Markus

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

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


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


Re: [OSM-talk] Editing road geometry Australia

2019-01-10 Thread Maarten Deen

On 2019-01-11 07:16, Petra Rajka - (p) wrote:


Since January we started to work on road geometry in Canberra, Perth
and Melbourne and we came across some intersections where roads (turn
lanes) are mapped separately even where there is no physical divider
or chevron markings.

See below two cases where we would simplify the geometry:

* -32.0914374, 116.0129206


Is seen no big problem in how the roads are layed out there. Coming from 
the motorway there is a clear divider where the offramp connects to the 
Albany Highway.
I have more problems with the tags of the on- and offramp. They are 
mapped as motorway when they should be mapped as motorway_link. The two 
bridges in the on- and offramp are mapped as motorway_link.



* -35.3409195, 149.1616891


Ways 77001149 and 77000891 should IMHO not be mapped like that but 
mapped with turn:lanes.


Regards,
Maarten

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


Re: [OSM-talk] Help - how to get rid of wrong image in wiki?

2018-12-19 Thread Maarten Deen

On 2018-12-19 22:30, Richard wrote:

the example image in 
https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dreversible

is clearly wrong but aparently isn't mentioned referenced anywhere in
the source
of the page. Am I blind?

Does it perhaps come from 
https://wiki.openstreetmap.org/wiki/Item:Q5736 ??


How the hell can I get rid of it?


I guess you can edit the Item:Q5736 page.
And the image is not entirely wrong, it's an example of a reversible 
oneway street.

https://en.wikipedia.org/wiki/Lions_Gate_Bridge

Regards,
Maarten

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


Re: [OSM-talk] [Osmf-talk] Board decision on Crimea complaint

2018-12-11 Thread Maarten Deen

On 2018-12-11 11:41, Frederik Ramm wrote:

Hi,

On 11.12.2018 11:16, Andrew Hain wrote:
A question both to the current board and the candidates: Do you 
support

normal levels of Board transparency on this issue?


Just as a "data point" in this discussion: There are people out there
who are happy to issue death threats to anyone who is seen to be
deciding something not in their favour.


Is transparancy meant as in personal accountability or transparancy as 
in clarity how the process works?
I hope it is the latter and that noone suggests that people be 
individually named and/or identified so they can "stand trial for their 
actions". IMHO that would not be a normal level of transparency.


Regards,
Maarten

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


Re: [OSM-talk-nl] Caribbean Netherlands

2018-11-07 Thread Maarten Deen

On 2018-11-08 01:48, Frederik Ramm wrote:


The groupings "ABC" and "SSS" seem to be rather informal; other options
would be to group everything in one and call it... well... "Nederlandse
Antillen" is not an official term any more, is it?


Not anymore, not since 2010. It used to be one country within the 
kingdom, now the 6 islands have their own status (some are 
municipalities, some are countries).



And "Caribisch Nederland" is just three of the six islands?


Yes, these are the three islands that are municipalities and therefore 
part of the country the Netherlands. But they are geographically not one 
entity.



One could also have
separate files for each but they would be *really* small. Is the 
ABC/SSS

grouping the obvious choice?


I would say yes.


I somewhat dislike the splitting of Saint Martin/Sint Maarten. I figure
that for all practical purposes, a map user would want to load a file
that contains both parts of the island, and it would be cumbersome to
have to pick the two halves out from underneath the Netherlands and
France (especially as there will be some overlap so combining the two
files can be difficult).


I hope that everyone can see that your downloads and splits are based on 
a convenience level rather than on a political level. I at least would 
be deaf to political views on this point.


Concerning: Sint-Maarten/Saint-Martin: I would include both in any 
download. The dataset is so small and it is logical.


Regards,
Maarten

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


Re: [OSM-talk-nl] afmelden

2018-11-07 Thread Maarten Deen

Hoi Gideo,

gebruik de link onderaan de mail 
(https://lists.openstreetmap.org/listinfo/talk-nl) en vul je mailadres 
in het onderste veld in en klik op "unsubscribe or edit options".


Groeten,
Maarten

On 2018-11-07 09:58, Biegstraaten, Gideon wrote:

Hoi,

Zou ik me af kunnen melden voor de OSM-talk-nl emails?

Alvast dank.

Met vriendelijke groet,

G.J.P. Biegstraaten (Gideon)

Adviseur/Projectleider Mobiliteit

T 06 - 18192106

g.biegstraa...@utrecht.nl

www.utrecht.nl/ [1]

Gemeente Utrecht

Ontwikkelorganisatie Ruimte

ma, wo en do

 [2]  [3]  [4]  [5]

 [6] [7]

  ­­

Links:
--
[1] http://www.utrecht.nl/
[2] https://www.facebook.com/GemeenteUtrecht
[3] https://twitter.com/gemeenteutrecht
[4] https://www.linkedin.com/company/gemeente-utrecht
[5] https://www.utrecht.nl/nieuwsbrieven
[6] https://www.utrecht.nl/
[7] https://www.utrecht.nl/pleegoudersgezocht
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


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


Re: [OSM-talk-nl] Splitting up Netherlands on Geofabrik Download Server

2018-11-06 Thread Maarten Deen

On 2018-11-06 11:12, Frederik Ramm wrote:


It sounds like a good idea to wait until the change is done - or
actually, perhaps it would not hurt if I simply implement the future
boundaries on the download server right now. Which of the provinces are
due to change?


Utrecht en Zuid-Holland and the new municipality will be in Utrecht.
See also 

Regards,
Maarten

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


Re: [OSM-talk-nl] Splitting up Netherlands on Geofabrik Download Server

2018-11-06 Thread Maarten Deen

On 2018-11-06 10:46, Bas Couwenberg wrote:

On 2018-11-06 10:35, Paul L. Smits wrote:

Keep in mind that the provinces will change in 2 months due to the
cross-provincial merging of three municipalities into the new 
municipality

of Vijfheerenlanden.


I already have the changes for the municipal changes on January 1st
ready, this includes the changes to the province borders.

AFAIK Frederik uses the boundary relations to create the poly files,
so those will just need to be refreshed when the boundaries change.


Maybe it is best for Frederik to wait until after january 1st to 
implement the split of the planet files. Idk but it may cause adverse 
effects to people if the planet you download all of a sudden has a 
different area.


Regards,
Maarten

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


Re: [OSM-talk] it seems josm.openstreetmap.de is down

2018-10-30 Thread Maarten Deen

On 2018-10-30 17:29, Oleksiy Muzalyev wrote:

I cannot open the link https://josm.openstreetmap.de/ and I cannot
launch the JOSM application on macOS.

I do not know if these two issues are connected.


I believe there is some maintenance going on. I think they planned a few 
hours of downtime.


Regards,
Maarten

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


Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

2018-10-26 Thread Maarten Deen

On 2018-10-26 14:22, Valentina Böhm wrote:


What would you recommend regarding authentication? Is it ok if users
of my app are committing data on my behalf or should all users have
their own OSM account?


I would not let users edit on your account. Then you will get the 
comments and possibly grief if edits are not correct.
I would require the users to use their OSM account or give the 
possibility to add an anonymous note. You can use OAuth for 
authentication.


Regards,
Maarten

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


[OSM-talk] Zoom to search results on the map

2018-10-26 Thread Maarten Deen
When you search on something in the searchbox on openstreetmap.org that 
returns multiple results, the map moves to the first result and when you 
hover over the result it displays a marker.
But for all the other results, you need to click to see where it is. 
This removes the search results and displays details of the object you 
clicked.  Suppose this is not what you're looking for, you now have to 
enter the search parameters again and nominatim now searches from the 
last point the map was centred at. So the search results differ from the 
first try. Now you have to remember what results you've looked at so you 
don't look at them again.


Is there no way to show the second, third, etc, result on the map 
without removing the search results?


Regards,
Maarten

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


Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

2018-10-20 Thread Maarten Deen

On 2018-10-20 03:33, Daniel Koć wrote:

W dniu 19.10.2018 o 07:39, Maarten Deen pisze:


Does this mean that amenity=atm only gets rendered in zoom 19 and
higher? If so, why? It is now rendered from 17 onward, shops get
rendered from 18 onward.
It seems to me that atms are at least as important as shops.



Yes, you get it right. I based this solution on size principle, because
this is the only universal rule I know that helps managing the mess
which is best visible on z17 in big, well mapped cities. Here are two
real life illustrations of the problem with small amenities I gave
during long and hot discussion:


https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-423373856
https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-426308795


With that argument you can delete all icons because "well mapped cities 
are cluttered". Maybe there needs to be done something about that, 
instead of not showing information everywhere.
There is not even a hint that there is something now. Shops already get 
mapped as dots first, now atms are just invisible except at the highest 
zoom.

Sorry, but IMHO this is a bad change.

Maarten

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


Re: [OSM-talk] OpenStreetMap Carto release v4.15.0

2018-10-18 Thread Maarten Deen

On 2018-10-19 05:43, Daniel Koć wrote:


- Moving amenity=atm to z19+


Does this mean that amenity=atm only gets rendered in zoom 19 and 
higher? If so, why? It is now rendered from 17 onward, shops get 
rendered from 18 onward.

It seems to me that atms are at least as important as shops.

Maarten

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


Re: [OSM-talk] Nabble deletes posts

2018-10-11 Thread Maarten Deen

On 2018-10-11 11:35, Martin Koppenhoefer wrote:

someone replied in private:


Hi Martin, might this help
you?http://n8.nabble.com/help/Answer.jtp?id=53


but I am not sure how this is applying, and in particular, why these
posts? All messages are to the tagging mailing list, it is just 7 in
total (i.e. a tiny fraction of what I wrote to tagging) and from July
2017, e.g. my replies to this thread:
https://lists.openstreetmap.org/pipermail/tagging/2017-July/032742.html
and this:
https://lists.openstreetmap.org/pipermail/tagging/2017-July/032762.html


If they haven't been moved, then this should not be applicable

In summary, only root nodes are checked for deletion. This means that 
only threads that have been removed or inactive root level forums will 
be caught by the garbage collector process.


and the messages shouldn't get deleted.

Maarten

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


Re: [OSM-talk] [OSM-dev] How to find the way with the most relation memberships

2018-08-27 Thread Maarten Deen
And the ways that are in the bad relations are bogus too. A lot of 
relations only have way 482554372 and 496296681 in them, both ways with 
no tags but the name.
My guess for the existance of these ways is they were split of from a 
way "Ankara Otobüs Hatları Çalışması", where left somewhere out of error 
or for some purpose and forgotten.
Does not explain the multitude in bus relations with only those two 
ways, but I have seen duplicates of (bus) relations also in Germany, 
where bus xyz had 10 relations of which 9 had only one or two members. I 
put that down to user error or a bug in the editor (never got a response 
from the user).


I think it is safe to delete these ways and the relations if they become 
empty.

Maybe a note on the turkish part of the forum is in place.

Regards,
Maarten

On 2018-08-27 12:57, Jo wrote:

I found that quite intriguing... so I went to download. It turns out
that this way (with just a name tag, nothing else, located in a small
town 18 km south of Ankara) is member in 430 route relations that only
have 2 members. The total amount of ways in those 430 route relations
combined is 3.

The way is a member of 439 route relations in total, 441 relations
including 1 street and a 'network'.

Something doesn't seem quite right.

Polyglot

Op ma 27 aug. 2018 om 12:36 schreef Frederik Ramm
:


Hi,

On 27.08.2018 11:41, Simon Poole wrote:

Come on, you're  leaving us out on a limb. Now we want to know the

world

leader in relation membership :-).


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

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
E008°23'33"

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

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


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


Re: [OSM-talk] As Google Maps Renames Neighborhoods, Residents Fume - The New York Times

2018-08-16 Thread Maarten Deen

On 2018-08-16 16:03, Tom Pfeifer wrote:

On 16.08.2018 13:06, Andy Mabbett wrote:

This may be of interest:

https://www.nytimes.com/2018/08/02/technology/google-maps-neighborhood-names.html


Scary. Can we revert Google?


Google does not seem to take much responsibility. When you look at the 
dutch version of Google Maps, they have a lot of cities translated to 
what they think are names we use.

Some we do, some we don't. Or have never done.
For instance: Paris in dutch is Parijs and gets used a lot. An archaich 
name for Ljubljana is Laibach and was mostly used in germanic countries, 
but never really used in the Netherlands. Guess what Google chooses to 
show dutch users of Google Maps when they look at Ljubljana.
This has been pointed out to Google many, many times (through their 
inadequate feedback tool and via Google employees) and has long been 
ignored. It has now been corrected, as well as the nearby town of 
Marburg an der Drau, but in Northern France we still see Sint-Omaars, 
Ariën-aan-de-Leie en Dowaai.


And sometimes they make really stupid translations. The Dutch town of 
Balk is translated to Balke in German and Beam in English. Yes, that is 
the correct translation for the technical structure, but no sane person 
would use that for the town's name and it has never been an official 
translation.


Regards,
Maarten

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


Re: [OSM-talk] highway=* + area=yes vs area:highway=*

2018-08-08 Thread Maarten Deen
Then I still don't understand the problem. A closed way tagged with 
highway=* will by default route. A closed way with area:highway=* will 
not. You'll have to introduce logic in the router to do so.


Regards,
Maarten

On 2018-08-08 14:49, john whelan wrote:

I don’t get why highway=footway + area=yes is considered as wrong

tagging !

The problem is consistency.  If the renderers and routers don't
understand your tagging then it is less visible.

Cheerio John

On 8 August 2018 at 08:40, djakk djakk  wrote:


I don’t get why highway=footway + area=yes is considered as wrong
tagging !

djakk

Le mer. 8 août 2018 à 12:52, Tomasz Wójcik  a
écrit :


As highway=footway etc. tags are set to "should not be used on
areas" on Wiki, and mapping them in combination with area=yes is
not documented at all and considered as wrong tagging by part of
users, there is a key "area:highway=*" (133k uses at the moment).
Part of users still map footway areas as a combination anyway,
propably because it's rendered by default style. Due to our rules,
that we shouldn't have 2 active tagging schemes for the same
feature, so we should discuss this topic.

I vote for area:highway=* key, because it's simpler, and it gives
a possibility to show also street areas with crossings in the
future.

* Wiki with specyfications of a:h=* for certain keys:
https://wiki.openstreetmap.org/wiki/Key:area:highway [1]
* TagInfo: https://taginfo.openstreetmap.org/keys/area:highway [2]
* area:highway=* visualisation: http://osmapa.pl/w/area [3]

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


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




Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:area:highway
[2] https://taginfo.openstreetmap.org/keys/area:highway
[3] http://osmapa.pl/w/area
[4] https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


Re: [OSM-talk] Paper/Article about stagnation in OSM

2018-08-03 Thread Maarten Deen

On 2018-08-02 22:14, john whelan wrote:

Lat and long work quite well.  If you have a smartphone with GPS it
understands lat long.  It may not understand 8 letter addresses.  Some
combination of letters may offend. How would you space them out?


It is What3words all over again, and some people don't seem to 
understand why that won't work or is not a better solution than what's 
already available.
What3words (or the like) only works if you have a computer (or 
smartphone) to search for your address. But if you have one, then there 
is also no need for a simple to understand location scheme (like 
fish.market.smells) because you have a device to store more complex or 
less easily rememberable addressing schemes like a lat-lon pair.
Granted, a lat-lon pair only works if you have GPS, but the same is true 
for What3words, and you need that GPS anyway to get to your location. 
The extra penalty for What3words is that you also need an active 
internet connection (or a huge offline addressing database) to convert 
the three words to a location. So it is never easier than a lat-lon 
combination. If you don't have this internet connection (which is more 
likely in remote areas where there is no proper addressing scheme) then 
you're SOL or JWF.
What's more: with lat-lon you can judge the distance between locations 
just by looking at it. With What3words this is absolutly impossible.


So Oleksiy, your comment about developers living in stable places 
applies equally well to the notion that What3words or your scheme would 
work. It does in a stable developed area, but does not in the outback.


Just to give an example: last week I was in a field where an animal was 
in distress. I needed to call the police and alert them to the 
situation. I needed to communicate the location. Is it easier and 
quicker for me to first open some app to try and find my 8 letter 
location or my 3 What3words, or is it easier and quicker to just read 
out my gps location?


Regards,
Maarten


On 1 August 2018 at 03:37, oleksiy.muzal...@bluewin.ch
 wrote:


Hi,

I read the whole article. I agree with the author's main idea, -
software development and implementation has got the invisible social
undercurrents, which are as important as the technical issues. By
the way, it is true for any human endeavor .

Speaking of database structure, - I am thinking about creating a
notion of an address. More than half of the planet population does
not have addresses because streets
do not have (and will never have) names, houses do not have numbers,
etc. Besides, in some areas addresses are unstable due to various
socioeconomic reasons.

At the same time it is possible to create 208 billion of 8-letter
unique quasi-words with 26 letters of English alphabet (26 in the
power of 8 = 208827064576). Even more if numbers are included. It's
enough for all dwellings on Earth. It is easy to transmit a 8 letter
word via telephone with ICAO Phonetic Alphabet [1].

Then when we call in browser something like:
osm.org/?address=hj3u878s [1] or type the unique quasi-word into a
search of of the OSM map: the distinctive geo-marker appears at the
respective location with the additional information, such as
entrance door code, apartment level, etc.

There are several commercial projects which attempt to do something
similar. And I realize that this approach may fail. However, the
path to success is paved with failures.
So at least it's worth giving it a try.

However, most developers live in stable places where street names
did not change from the 19th century. They may not realize that lack
of addresses leads to situations
where people cannot call police, firefighters, ambulance, etc. In
fact they can call but cannot explain where they live. What
consequently leads to the social issues such as appearance of
alternative criminal "authorities", sub-quality healers, etc.

[1]
http://aviationknowledge.wikidot.com/aviation:nato-phonetic-alphabet
[2]

Best regards,
Oleksiy

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




Links:
--
[1] http://osm.org/?address=hj3u878s
[2] 
http://aviationknowledge.wikidot.com/aviation:nato-phonetic-alphabet

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


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


Re: [OSM-talk] anonymous notes spam?

2018-07-20 Thread Maarten Deen
I assume the anonymouse notes have been deleted, since the notes that 
are now visible are not anonymouse.


Regards,
Maarten

On 2018-07-20 20:21, Johnparis wrote:

When I click on the samples I get full notes. Perhaps there was a
database hiccup?

On Fri, Jul 20, 2018, 18:29 Andrew Hain 
wrote:


Can we find out what software is being used to send these notes?

--
Andrew
-

FROM: Doug Hembry 
SENT: 20 July 2018 14:26:13
TO: talk@openstreetmap.org
SUBJECT: Re: [OSM-talk] anonymous notes spam?

Yes. In the San Francisco Bay Area. Single letters "f", "k", and
"l".
Example:


https://www.openstreetmap.org/note/778721#map=15/37.5009/-122.3032=N

BTW, is there a simple way to delete such note comments?

On 7/20/2018 2:32 AM, maning sambale wrote:

I'm getting several single letter notes comments since yesterday.
Example: https://www.openstreetmap.org/note/562375
Are people noticing the same?



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

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


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


Re: [OSM-talk] API a lot slower?

2018-07-19 Thread Maarten Deen

On 2018-07-19 09:04, Roland Olbricht wrote:

Hi Maarten,


Nothing special really, I was just downloading the data from a lot of
relations sequentially in JOSM. I downloaded relation 1360154 with its
members which are bus master_relations that then also load the bus
relations but without their contents, and then I selected all the bus
relations and downloaded the members (in JOSM: select all relations 
and

do "download members").


By the way: Please consider to use "Download data > from Overpass"
with the query

( rel(1360154); >>; );
out meta;

The runtime is expected to be 3 to 10 seconds, data is usually less
than two minutes off. As a side effect, this takes load off the Main
API.


Thanks, that is a good tip. I am in a habit of doing that when 
downloading nodes or ways with a certain k/v combination in an area, but 
haven't yet done it with relations in that way.


Regards,
Maarten

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


Re: [OSM-talk] API a lot slower?

2018-07-18 Thread Maarten Deen

On 2018-07-18 15:50, Tom Hughes wrote:

On 17/07/18 10:42, Maarten Deen wrote:

Is it just me or just today or is the API a lot slower after the move 
on sunday? I'm downloading a number of busrelations and it takes a lot 
longer than before the weekend.


I know the cause of this has been explained already but I'd be
interested to know exactly which API call you are referring to
here as it may be that (long term at least) there is something
here which should be fixed but it rather depends if it is a call
being handled by rails or one being handled by cgimap.


Nothing special really, I was just downloading the data from a lot of 
relations sequentially in JOSM. I downloaded relation 1360154 with its 
members which are bus master_relations that then also load the bus 
relations but without their contents, and then I selected all the bus 
relations and downloaded the members (in JOSM: select all relations and 
do "download members").


From the Java console:
2018-07-18 19:13:55.553 INFO: GET 
https://api.openstreetmap.org/api/0.6/relation/7449166/full -> 200

and that for about 320 relations.

Regards,
Maarten

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


[OSM-talk] API a lot slower?

2018-07-17 Thread Maarten Deen
Is it just me or just today or is the API a lot slower after the move on 
sunday? I'm downloading a number of busrelations and it takes a lot 
longer than before the weekend.


Regards,
Maarten

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


Re: [OSM-talk] Database on readonly?

2018-07-15 Thread Maarten Deen

On 2018-07-15 12:38, Andy Townsend wrote:

On 15/07/2018 11:29, Maarten Deen wrote:


What is the problem? Is there maintenance going on?


Nothing on the "announce" list
https://lists.openstreetmap.org/pipermail/announce/ , but it was
mentioned at https://mobile.twitter.com/osm_tech (and in last week's
OSM weekly news)


Thanks. So many places to convey information but you just have to read 
the correct one :/


Regards,
Maarten

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


[OSM-talk] Database on readonly?

2018-07-15 Thread Maarten Deen
There is a message on the map at openstreetmap.org that the database is 
readonly because of maintenance and in JOSM I can't download anything.
I've seen no announcement and the platform status at 
https://wiki.openstreetmap.org/wiki/Platform_Status gives everything OK.


What is the problem? Is there maintenance going on?

Regards,
Maarten

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


Re: [OSM-talk] Scientific paper on "Information Seeding"

2018-07-09 Thread Maarten Deen

On 2018-07-09 11:55, James wrote:

From what I understand TIGER data is very poor quality to begin with
and is at a federal level, this study doesnt take into account local
GIS data(say a city or a province/state data) which often is more
accurate. It seems fixated on one data import instance vs many in
statististics their sample size would be too small to draw a
conclusion


I agree with that. What I've seen from the TIGER data it is not 
conducive for a good mapper ecosystem. Yes, it will function to show a 
map that is moderately accurate, it might function if you want to use 
the data for routing purposes and maybe even for guided navigation, but 
virtually all information needs fixing so the amount of work you have to 
do to get a correct map is still humongous. And then you get parts which 
are corrected and part which are not and the casual dataconsumer can not 
really distinguish them.


Compare that with the AND import of the Netherlands where the data was 
accurate and needed only minor fixing but where the bulk has just been 
untouched (except for adding metadata) and is still the base of the map 
in the Netherlands.


So the one import cannot be compared to the other and conclusions drawn 
from one can not be extrapolated as being the truth.


Regards,
Maarten


On Mon, Jul 9, 2018, 5:05 AM Warin, <61sundow...@gmail.com> wrote:


On 09/07/18 18:35, Christoph Hormann wrote:


And if you want to know about how to successfully map and build a

local

mapping community in a large and sparsely populated country and

are fed

up with the namby-pamby western Europeans who don't know a thing

about

this maybe talk to the Russians...


Yep.



All to easy to be critical .. but so what?
Getting people to contribute to the map is what it is about.
There is one guy on Quilpie Queensland Australia who has made good
contributions to the map - he is local .. so knows what is there.
The edits may not be the 'best' but they do indicate what is there..
I've edited some of them to make them OSM 'better' but tried to keep
the original information.
Yet to contact him to let him know .. but good on him for putting
his foot in the water.
Don't think there is much chance of getting a local group out there
.. unless you count 1 as a group.
And maybe one is all it takes in smaller places.
Officially Quilpie's population is less than 600.

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

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


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


Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

2018-07-03 Thread Maarten Deen

On 2018-07-03 22:07, Tobias Knerr wrote:

On 03.07.2018 10:28, Frederik Ramm wrote:



Software should be able to deal with both.


In my opinion, software should not _need_ to deal with both. Working
around easily fixed database quality issues is a waste of time.


Good softwaredesign dictates "Be conservative in what you do, be liberal 
in what you accept from others". Calling that a waste of time is IMHO 
not a good standpoint.
Especially since in this case you do not fix anything. As said many 
times, anyone can add a FIXME tag to the data and then you would again 
overlook it. Until the next automated edit comes around and "fixes" the 
FIXME tags.


Regards,
Maarten

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


Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

2018-07-03 Thread Maarten Deen

On 2018-07-03 11:23, Mateusz Konieczny wrote:

3. Lipiec 2018 10:36 od md...@xs4all.nl:


What will prevent users from adding FIXME tags in the future?


Nothing, users may add any tags. It is impossible to change that by
edits.


Then the proposed mechanical edit is useless. It will have to be 
repeated periodically, and I don't think that should be how we do QC for 
this problem.
If this is a problem, it needs to be fixed at the root (change the API 
to accept lowercase keys only or change every key to lowercase on 
upload) and then corrected (this proposed mechanical edit).


Regards,
Maarten

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


  1   2   3   4   5   6   7   8   9   10   >