[OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

[Imre Samu]

Courtney  ezt írta (időpont: 2023. ápr. 30.,
V, 19:06):

> This conversation has opened up important new questions.  Why is the main
> "Talk" channel the only one that is producing pushback? Why is it the only
> one that is producing such a negative tone?
>

Hi Courtney,

I think it's important to mention the problems arising from *intercultural
differences*
in your SOTM US - OSM Communication Presentation, as the OSM community
currently struggles with misunderstandings between different cultural
groups.

Although the "OSM Diversity Statement" has been accepted, its practical
implementation isn't fully successful yet. *Ethnocentric attitudes* need to
be addressed, and we must be more open to other cultures. However, this is
easier said than done.

IMHO:
Most conflicts within the OSM community and on the OSM-Talk mailing list
are due to *intercultural differences,* and there's no current mediation or
conflict resolution in place. It might be helpful to have "intercultural
mediators" who can bridge the gap between cultures and help understand
other cultural groups.

I mainly notice the clash between American and EU/German cultures, but
other cultural conflicts are likely as well.

Probably the EU/German OSM community needs to learn how to wrap their raw,
honest messages in a sugar coating, making it more palatable for those with
an American cultural background. Conversely, the American community should
strive to be less sensitive towards differing norms from other cultural
communities, embracing the deep-level diversity that comes with global
collaboration. ( [1], [2]  )

Unfortunately, the current OSM Etiquette Guidelines [
https://wiki.openstreetmap.org/wiki/Etiquette/Etiquette_Guidelines ]  do
not provide much assistance in understanding and resolving intercultural
issues. To improve the guidelines, it would be beneficial to incorporate
information on intercultural communication and provide resources to help
community members navigate these challenges effectively. This would promote
a more inclusive and harmonious environment within the OSM community.

In addition to this, new OSM community members should be prepared for the
potential culture shock they may encounter, especially those who come from
a top-down corporate environment. It's important to remember that
OpenStreetMap is characterized by a bazaar-style, bottom-up communication
approach, which may be an adjustment for some. Embracing this unique aspect
of the community will help newcomers adapt and thrive in the OSM
environment.

In fact, this is a big topic, and when I consider the OSM community
problems from the past few years through the viewpoint of cultural
differences, it gives me a good understanding of the reasons.

Generally, the OSM Talks mailing list is characterized by *"deep-level
diversity," and as a result, more productive conflicts are expected than
usual,* which is normal based on some diversity research [3]. This means
that diverse perspectives and experiences can lead to more engaging
discussions and ultimately result in innovative solutions and ideas for the
community.

I would be curious about others' opinions as well. To what extent can
cultural diversity be a problem? And how can we alleviate conflicts and
amplify the advantages arising from cultural differences?



contexts:
[1]
*""According to Hofstede, a typical conversation in a German cultural
context is characterized by a large degree of honesty, even if it hurts.*






*Consequently, Germans are perceived to be among the most direct
communicators in the world (Yin, 2002).Presumably, the strategy “be honest
even if it hurts” offers the other party the opportunity to understand and
learn from possible mistakes.In a qualitative study, Yin (2002) explored
the concept of  German wahrheit (truth), in terms of a German standard for
communicating in public.She describes wahrheit as expressions of an
individual’s personal opinions, using the first pronoun: “The wahrheit can
be displayed in a manner that implicitly or explicitly indicates the
rightness of one’s own opinion. In public talk, as one German informant put
it, ‘Telling the wahrheit hurts a little bit, but it’s okay’” (Yin, 2002,
p. 249).  As a result, frank and forthright discussion with open
disagreement for the sake of the discussion is preferred" Indeed, not
directly telling the wahrheit was perceived as hiding personal opinions or
lying by the German participants in Yin’s (2002) studyAdditionally,
Yin’s (2002) findings suggest that German and U.S.-American meetings might
differ in terms of the frequency of counteractive meeting behaviors. Her
finding that Germans were more outspoken, cared particularly for telling
the honest truth (even if it hurts), and expected others to do so as well,
could imply a higher tendency to show counteractive behavior. For example,
complaining as one type of counteractive behavior can also be an expression
of honest criticism of the current situation. Similarly, complaining can 

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[Imre Samu]

some info for the planning :

>  Wikidata names. I'm guessing thats because they are simply better
quality,

most of  the labels /names generated/transliterated  by bots ..
or imported from other databases ( GeoNames !! )

> better modeled, better referenced

Wikidata:  The Cathedral style ... top-bottom
OpenStreetMap:  Bazaar style data model:  ... bottom-up

in the OSM .. There are a lot of name tags :
https://taginfo.openstreetmap.org/search?q=name
and it is not easy  to map everything to the wikidata model.

Wikidata is a graph database .. and there is a "known" scalability problem
https://lists.wikimedia.org/pipermail/wikidata/2019-June/013124.html

*"Scaling graph databases is a "known hard problem", and we are reaching*
*a scale where there are no obvious easy solutions to address all the*
*above constraints. At this point, just "throwing hardware at the*
*problem" is not an option anymore."*



can't protect against bad import ..  no strict  community rules ...
for example -  the cebwiki  re-imported the full GeoNames database ...
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/06#A_proposed_course_of_action_for_dealing_with_cebwiki/svwiki_geographic_duplicates
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/07#Another_cebwiki_flood%3F
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2017/10#Cebuano

> and better protected against vandalism.

anyone can modify the wikidata - without registration.
in the wikidata JSON dump - no user info .. so it is hard to detect the
modifications type ( from logged or unlogged users )


Best,
 Imre

pangoSE  ezt írta (időpont: 2020. aug. 9., V, 10:29):

> I suggest we create a roadmap for deprecating of storing and updating
> names in OSM for objects with a Wikidata tag.
>
> The rationale is explained here:
> https://josm.openstreetmap.de/ticket/19655
>
> This of course affects the whole project and data consumers as well. Every
> OSM user will have to become a Wikidata user as well to edit the names or
> add name references (through the editors)
>
> Substantial changes will have to be made:
> * nominatim will need to support fetching names from wikidata somehow. It
> could probably be done on the fly.
> * openstreetmap.org will need to fetch from wikidata when displaying any
> object.
> * rendering the standard map will have to support fetching from wikidata.
> * all editors would have to fetch and enable editing of Wikidata objects.
> * maybe it no longer makes sense to have 2 separate logins? We should
> unify the logging in as much as possible. Ideas are welcome on how to do
> that. Perhaps retire signing up as OSM user on osm.org and ask users to
> create a Wikimedia account instead and log in with that?
>
> I personally don't see any problems connecting Wikimedia and OSM closer
> than the islands they are today.
>
> As mentioned in the ticket above data consumers like Mapbox already prefer
> Wikidata names. I'm guessing thats because they are simply better quality,
> better modeled, better referenced and better protected against vandalism.
>
> WDYT?
>
> Cheers
> pangoSE
> Ps I choose this list because this not only relates to tagging, but to the
> wider ecosystem.___
> 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] Crimea situation - on the ground

[Imre Samu]

> but also reaffirms that it supports the on-the-ground-rule

I suggest to extend our manifesto [1] with the word "emphatic"
( adding after the list:  Truthful, Legal, Verifiable, Relevant,
+Emphatic )

With adding the "empathy"  to the "on the ground rule"  ->  it is adding
the extra layer of the meaning.

Without "empathy" - we can map* "nesting locations of vulnerable species"*
- because of the cold logic of the "*on the ground rule"*
With "empathy" we can fix the side effects of cold logic, and we can make
an "intelligent" decision  [2]

With "empathy"  - it is easy to solve the diversity problems.[4]
Without "empathy" - just with cold logic -  it is impossible.

With "empathy" - this sentence has a deeper meaning:
*"OpenStreetMap values community cohesion over data perfection." [1] *

and this is important for every organisation/community:

*"Empathy deserves its buzzy status, and leaders are wise to desire it for
their businesses. But to succeed in making it part of their organization’s
DNA, they must pay close attention to how cultures build and change —
organically, collectively, and often from the bottom up."  [3]*


And in the "Crimea situation"  the empathy add an extra complexity ..
What is the real meaning of the "Our community is based on mutual respect,
tolerance ..." [4]  in this case?


[1] https://wiki.openstreetmap.org/wiki/How_We_Map
[2] Eugenia Cheng: "The Art of Logic: How to Make Sense in a World that
Doesn't"
https://youtu.be/YHZKX0H6cUE?t=2217
[3] https://hbr.org/2019/05/making-empathy-central-to-your-company-culture
[4] proposed "Diversity Statement" *"Our community is based on mutual
respect, tolerance ..."*  ~ empathy
https://gist.github.com/grischard/53e4e9defebe7912f3aab9c0d2d1b55a

Best,
 Imre


Martin Koppenhoefer  ezt írta (időpont: 2020. febr.
6., Cs, 12:42):

> As most of you will know, the DWG on 14 Nov 2018 had reconsidered its
> original statement on Crimea from 5 June 2014, and decided to acknowledge
> that on the ground, Russia was controlling the territory and that the
> situation seemed fairly stable. On 10 December 2018, the OSMF board decided
> to return to the 2014 resolution. In its reasoning, board refers to the
> community as a whole ("The previous situation with the exception in place
> was obviously much more acceptable to the OSM community as a whole"), but
> also reaffirms that it supports the on-the-ground-rule: "
>
> We recognize that a lot of work has gone into the current Disputed Area
> Policy, and both DWG and LWG have assured us that the "on the ground
> rule" generally works well to avoid and settle conflicts. We, therefore, do
> not want to weaken that policy."
>
> My belief is that the reason for the on-the-ground rule to exist, is
> actually solving problems like the one in Crimea, and that we are weakening
> our position as "neutral", global community, if we make any exceptions to
> the rule. While I fully support the 2014 DWG resolution for the situation
> of 2014 (indeed potentially unclear if it would be stable), I also agree
> that in 2018 DWG couldn't decide differently than how they did.
>
> I therefore ask the current OSMF Board to reconsider the 2018 board
> decision and put the updated DWG statement from Nov 2018 into effect. This
> is not a question whether you believe, Crimea should belong to Ukraine or
> Russia, it is a principal question of creating together a truely impartial
> and indipendent map and adhering to our own standards.
>
> Like the former OSMF board, the DWG and LWG, I do not want to weaken that
> policy.
>
> Cheers
> Martin
>
>
>
> _
>
> https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2018-11-14_Crimea
>
> https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2014-06-05_Special_Crimea
>
> https://lists.openstreetmap.org/pipermail/osmf-talk/2019-February/005972.html
> ___
> 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] We got permission to continue tracing from Strava

[Imre Samu]

> Also the Strava fork of iD might still be working. See
> http://strava.github.io/iD/#background=Bing=17.00/-110.02947/53.27094

be careful, it is extreme old:  1.8.5-slide( based on ~4y old iD editor
version [1] )
The production version on the iD editor (openstreetmap.org)  is now :
2.16.0
Discussion https://github.com/strava/iD/issues/14

[1] https://github.com/openstreetmap/iD/tree/v1.8.5 ( Last commit  Jan 18,
2016 )

Best,
Imre



pangose  ezt írta (időpont: 2019. nov. 16., Szo, 8:33):

> Good news for OSM!
> https://wiki.openstreetmap.org/wiki/Permissions/Strava
>
> Also the Strava fork of iD might still be working. See
> http://strava.github.io/iD/#background=Bing=17.00/-110.02947/53.27094
>
> Hooray 
>
> Cheers
> pangoSE
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html
>
> ___
> 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] Birthplace of artist - how to map with Wikidata?

[Imre Samu]

> ... I wanted to express "person P was born in building B" in Wikidata,

imho: my proposal for example for "Haydn's birthplace"

one tag for a memorial

historic=memorial
memorial=plaque
name=.
subject:wikidata=Q7349( https://www.wikidata.org/wiki/Q7349  Joseph
Haydn )  it is an extra;  but useful for some programs.


and another tag for the building.

building=
wikidata=Q1375165   ( https://www.wikidata.org/wiki/Q1375165 Haydn's
birthplace )


--

there is a https://www.wikidata.org/wiki/Q19979289

*"building where someone was deemed to be born, not a hospital. Add this in
P31 in addition to properties about the architecture or function of the
building. If it's the actual place of birth of the person, add the house in
P19 of the person's item"*


searching for examples  ( instances of Q19979289 )   with "wdtaxonomy -i
Q19979289"   [1]for creating similar wikidata items
 -Haydn's birthplace (Q1375165)
 -birthplace of Franz Liszt (Q1445881)
 -birth house of Jean-François Millet (Q3280233)
 -birth house of Joan of Arc (Q3280236) (
https://www.openstreetmap.org/way/161619115 )
 -birthplace of Leonardo da Vinci (Q3280239)
 -birthhouse of Victor Hugo (Q3280244)
 -Mozart's birthplace (Q3327039)   (
https://www.openstreetmap.org/node/265024462 )
 -birthplace of Ronald Reagan (Q4917087)
 -Bashō's birth house (Q11614939)
 -birth house of Bedřich Smetana (Q12049583)
 -birthplace of Adlai E. Stevenson II (Q14681610)
 -birth house of Blas de Lezo (Q20492856)
 -birth house of Franz Schubert (Q28653671)
 -birth house of Antonín Dvořák (Q29018403)
 -Bob Marley birthplace in Nine Mile (Q61745553)
- 

[1] https://github.com/nichtich/wikidata-taxonomy

Imre


James  ezt írta (időpont: 2019. szept. 25., Sze,
12:03):

> https://wiki.openstreetmap.org/wiki/Tag:memorial%3Dplaque
>
> historic=memorial
> memorial=plaque
> name=[what ever the plaque says]
>
> On Wed., Sep. 25, 2019, 5:56 a.m. Frederik Ramm, 
> wrote:
>
>> Hi,
>>
>> I passed a building today that had a plaque saying that a famous writer
>> was born there ("on the first floor of this house") in 1901.
>>
>> I could add a note to the building in OSM (but that would not be machine
>> readable), or I could add a separate object for the plaque, again with a
>> note tag. But I think that this particular information is perhaps a bit
>> too much for OSM. Perhaps it would be better to model this in Wikidata.
>>
>> But how? The building itself is nothing of note. I guess that if I
>> wanted to express "person P was born in building B" in Wikidata, I would
>> have to create a representation of B in Wikidata, and could *then* link
>> to B in Wikidata from the OSM building. But this item representing B in
>> wikidata would be totally featureless (linked FROM osm, and linked FROM
>> from the author's entry, but not itself linking anywhere, nor having any
>> properties other than "is a building"). Is that even possible, or would
>> it quickly be deleted in wikidata as not making sense on its own?
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> 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] Burger King in ID

[Imre Samu]

thank you for the report!
I have created an issue :
https://github.com/osmlab/name-suggestion-index/issues/2798

best,
 Imre



Jack Armstrong dan...@sprynet.com  ezt írta
(időpont: 2019. jún. 16., V, 0:22):

> When I try to tag something as the fast-foot chain, Burger King in ID, the
> preset Burger King logo pops up as an upside down "Stranger King" symbol.
> ___
> 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] Your thoughts on osm.org

[Imre Samu]

>Imagine the openstreetmap.org home page, but without the map.

I like the https://www.openstreetmap.fr/  and https://www.openstreetmap.de/
landing page.
I would like more focus - on [community + software tools + data ]
 ( but the map is also important!   Please don't remove! :)  )

imho: we need to answer the "Why OpenStreetMap?" question on the landing
page.
And the answer is so different for
- hiking, railway, tourism, local patriotism, disabled people, humanitarian
osm,  open data lovers.

We need to answer the
- "How you can start?"
- "The results?"

Imre


Martijn van Exel  ezt írta (időpont: 2019. márc. 12., K,
18:02):

> Hi all,
>
> Here’s something I ask myself from time to time and would like to hear
> other people’s thoughts about.
>
> Imagine the openstreetmap.org home page, but without the map.
> What would the home page be about instead? What would be on it?
>
> Thanks for sharing,
> Martijn
> ___
> 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] Grab using OSM Data for route preview

[Imre Samu]

Techcrunch: "Grab is messing up the world’s largest mapping community’s
data in Southeast Asia
Remote teams incorrectly overwrote data developed by volunteer mappers in
Thailand"
https://techcrunch.com/2018/12/19/grab-maps-osm-thailand-southeast-asia/

Hacker News: https://news.ycombinator.com/item?id=18723138  ( Please
somebody add our community view )



Christoph Hormann  ezt írta (időpont: 2018. dec. 19., Sze,
12:10):

> On Wednesday 19 December 2018, Martin Koppenhoefer wrote:
> >
> > bist Du nicht im advisory board? Hast Du mind 1 Eur bezahlt?
> > Kommt mir unwahrscheinlich vor ;-) Oder bringe ich da was
> > durcheinander?
>
> I am on the AB because the FOSSGIS sent me there (and neither i not the
> FOSSGIS paid anything for that).  If i wanted to be there on my own
> accord i would have to pay EUR 10k as well.
>
> And to my knowledge no one ever accused the FOSSGIS or any other OSMF
> local chapter for insufficient attribution. :-)
>
> Glad to hear the LWG is working on clearer attribution guidelines -
> please make sure to clearly condemn second rate attribution like on:
>
>
> https://www.zeit.de/politik/ausland/2016-07/china-hat-keinen-gebietsanspruch-auf-inseln-im-suedchinesischen-meer
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Imre Samu]

> Vector tiles and customizable styling is not enough.
> So we still need to represent the various viewpoints on disputed borders
and territories within the OSM database itself

agree,   (  sorry,  I am not good at communication. :))

as I wrote:

Imho: an important part of the solution:
-  openstreetmap.org vector maps.  ( so we can customize the borders,
languages for  the end users, communities )
-  improved admin border tagging
-  more communication,  adapting the rules for the current political
situations.

And I trust in DWG.





Eugene Alvin Villar  ezt írta (időpont: 2018. dec. 11.,
K, 16:41):

> On Tue, Dec 11, 2018 at 10:02 PM Imre Samu  wrote:
>
>> TLDR:  We need focusing for the customizable vector tiles for the next
>> year!(  Less community fighting - more working on the real problems!  )
>>
>
> Vector tiles and customizable styling is not enough. AFAIK, we never use
> 3rd-party data (except for the public domain Natural Earth data for the
> lower zoom levels, IIRC) when rendering the default tile layer on the OSM.
> So we still need to represent the various viewpoints on disputed borders
> and territories within the OSM database itself if you want that level of
> flexibility on the default tile layer(s). There are already a couple or so
> threads on the Tagging mailing list discussing various tagging solutions
> for representing these viewpoints and disputes.
>
> ~Eugene
> ___
> 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] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Imre Samu]

>https://wiki.osmfoundation.org/wiki/Mission_Statement says that OSM
favours objective ‘Ground Truth’ over all other sources.

:)

Imho:  there are other core values
core1. *"We want to make the best map data set of the world"* ( With
Ukraine!  - I don't want an OSMUkraine-Exit forking OSM , like Brexit
example in the today politics )
core3. *"OSM is powered by its Community. Engage positively with the
Community, be a good and respectful neighbour and assume good intent.""*
( I prefer collaborating with Ukraine community not fighting )
core5. *"Ground Truth: OSM favours objective “Ground Truth” over all other
sources""*

So we need to find a global optimum - and it is not easy.

Imho: an important part of the solution:
-  openstreetmap.org vector maps.  ( so we can customize the borders,
languages for  the end users, communities )
-  improved admin border tagging
-  more communication,  adapting the rules for the current political
situations.

I would like if we can create an OpenStreetMap Manifesto ( like
https://agilemanifesto.org/ )
- important point:We prefer community (nationality) collaboration over
the following rules

Disclaimer:
-  I am a native Hungarian,  and a lot of ethnic Hungarians live in the
neighboring countries  - so in Ukraine also (
https://en.wikipedia.org/wiki/Hungarians_in_Ukraine )
   A minority language is a hot issue in this area, but we need to
collaborate for every neighboring osm community.
   in this issue - no rationality only emotions.  So mentioning rational
"ground truth" is not enough.

so in my reading - We have a little time to focus on the root cause of the
problem   ->  * We don't have a customizable vector map yet.*

>I really think it is now time to apply the on-the-ground rule. We should
use the opportunity to reaffirm our core values,
>review with the community’s support where we have taken decisions on
disputed territories, and make sure that we apply the same rules in the
same way everywhere.

imho:  this is also important.
core values: *"OSM wants you to map the things you care about and will
ensure that you have the freedom to do so. This safeguards the
accessibility of our map to diverse users with differing needs."*

We need customizable vector tiles for Ukrainian map users!

Question:  What is the priority of the core values?

TLDR:  We need focusing for the customizable vector tiles for the next
year!(  Less community fighting - more working on the real problems!  )

this is my personal opinion.  ( but my opinion sometimes change )
( Sorry for my draft English, I respect every people on the DWG !   and
this is not so easy issue!  and a lot of unintended consequences,  +
complexity;  IMHO: we need an iterative solution! )

best,
 Imre




Guillaume Rischard  ezt írta (időpont: 2018. dec.
11., K, 11:52):

> Hi Rory and fellow members,
>
> I am a candidate in the board election, and have underlined in my
> manifesto how important it is that decisions like this are taken
> transparently. The detailed reasoning behind this decision must be
> published without delay.
>
> The lobbying from Ukrainians over the last days has been heavy. However,
> the on-the-ground rule is one of the very core values that we have built
> OSM and the OSMF on.
>
> https://wiki.osmfoundation.org/wiki/Mission_Statement says that OSM
> favours objective ‘Ground Truth’ over all other sources. The ‘Scope of the
> OSMF’ section says that it does not decide what to map or how to map.
>
> The on-the-ground rule has served us well on disputed borders: there is no
> other reasonable and possible alternative. Creating an exception in Crimea,
> without any justification, opens Pandora’s box. Would the OSMF react
> similarly to an appeal concerning other disputed borders? There should
> never be an arbitrary decision on these issues but only well-defined and
> established policies.
>
> You could claim that we haven’t followed the on-the-ground rule in Crimea
> for the last four years. I know that the Data Working Group, which I am a
> member of, has treated Crimea with kid gloves after the Russian invasion. I
> haven’t been on the DWG that long; this was decided way before my time. We
> act more as firefighters than as gardeners, work more reactively than
> proactively, and always have enough new issues to prevent us from
> reexamining old ones.
>
> I really think it is now time to apply the on-the-ground rule. We should
> use the opportunity to reaffirm our core values, review with the
> community’s support where we have taken decisions on disputed territories,
> and make sure that we apply the same rules in the same way everywhere.
>
> Guillaume Rischard (personally, not on behalf of the Data Working Group)
>
> > On 11 Dec 2018, at 11:18, Rory McCann  wrote:
> >
> >
> > Hi fellow members,
> >
> > I am curious what candidates to the board think about this decision. I
> > know there was the existing questions, but this is a new topic which
> > came up recently. But if you're a 

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Imre Samu]

> When I recently looked at Crimea I noticed it is still part of the
Ucraine in OSM: https://www.openstreetmap.org/relation/60199

And part of Russia:
https://www.openstreetmap.org/relation/60189#map=6/45.014/33.873=C

Imre

Martin Koppenhoefer  ezt írta (időpont: 2018. okt.
21., V, 15:15):

> Dear all,
>
> we all know how sensible the topic of disputed boundaries can be (they are
> not necessarily a big problem, many boundary disputes like between Italy
> and France about the summit of Mont Blanc / Monte Bianco, have little
> bearing on the actual life of people).
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
> As many might know, the current boundary situation for Crimea was frozen 4
> years ago “for a short time” by the DWG and so I asked them about their
> current position 2 months ago, and after I got no reply, tried to remind
> them 5 weeks ago, but have not yet gotten any reply, so I am now opening
> this thread here.
>
> IMHO, for consistency and credibility, we should either recognize that
> Russia is actually controlling Crimea, or we should update the disputed
> borders information. As I believe the general concept of ground truth for
> admin boundaries was a good idea, I would tend to the former.
>
> I also believe the actual situation has already been ignored for too long.
> When the thing is still dynamic or/and we’re in the middle of a conflict it
> can be wise to step back and see for some time how things are evolving, but
> 4 years are a lot of time, something like one year would seem more
> reasonable.
>
> What do you think?
>
> Cheers, Martin
>
> sent from a phone
>
> Begin forwarded message:
>
> *From:* Martin Koppenhoefer 
> *Date:* 20. August 2018 at 10:42:33 CEST
> *To:* d...@osmfoundation.org
> *Subject:* *DWG policy on Crimea*
>
>
> Dear members of the DWG,
>
> as of this question in the help forum:
>
>
> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>
>
> I kindly invite you to reconsider and eventually update your position on
> the situation in Crimea.
>
> As you have stated in 2014, this should not be the long term way to deal
> with the situation, and short term is probably coming to an end. There is
> clear guidance by the OSMF board how to deal with disputed boundaries (as
> the situation seems to be more stable than some would have liked).
>
> My motivation is not promoting the Russian point of view, but to act
> predictably and consistent wrt sensible topics.
>
> Thank you,
> cheers,
> Martin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proximity

[Imre Samu]

> If you live within a 5 minute walk of a bus stop on a route that goes
past the hospital then its easy to get to but how do you find these
locations using OpenStreetMap data?
>Many cities have had their bus stops imported.  If you are in one of these
what else is needed to work it out?

A lot of cities has a GTFS feed - with the latest public transport info it
can be combined with  OSM hospital info
see: https://www.mapnificent.net/  [ *"Shows you areas you can reach with
public transport in a given time"* ]

Best,
 Imre



john whelan  ezt írta (időpont: 2018. szept. 28., P,
23:24):

> I drifted down to a government conference on open data and software today
> and whilst there a question came up concerning proximity to a hospital.
>
> Just a planner wondering where to put it to maximise the ease of access
> for as many people as possible.
>
> You can route plan for walking and driving a car but what can you do for
> public transport.
>
> Essentially it is how many buildings are within 1 km for pedestrians, 3 km
> for cyclists, 7 km for a car.  I've chosen arbitrary numbers but public
> transit is quite different.  If you live within a 5 minute walk of a bus
> stop on a route that goes past the hospital then its easy to get to but how
> do you find these locations using OpenStreetMap data?
>
> Many cities have had their bus stops imported.  If you are in one of these
> what else is needed to work it out?
>
> The information is worth money.  The right location makes a business or
> amenity more valuable.
>
> What do we have?
>
> Is this the right forum to raise the problem?
>
> Thanks John
> ___
> 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] [test] Customized Taginfo : 620 areas - every country and some new experimental features ( ~ 1 week test )

[Imre Samu]

Hi Frédéric,

Thank you for the feedback.
I will recheck the big countries config files  ( France,  Russia, Canada,
Germany, U.S, Japan ) in the next version.

background:  I have started the development with 8GB RAM - and this is too
low for processing some countries.

Thanks,
  Imre


Frédéric Rodrigo  ezt írta (időpont: 2018. aug.
16., Cs, 15:24):

> Hello,
>
> It's an impressive job. It can really help.
> Just a note about France, you split France on admin_level=6, this result
> on around 100 pieces, it does not make sens. For France admin_level=4 is
> the only right level of sub area.
>
> Like for France or other countries, sub levels is interesting but the
> country as a whole also..
>
> Frédéric.
>
>
> Le 14/08/2018 à 20:26, Imre Samu a écrit :
> > This is a Proof of Concept of my vision [ customizing taginfo for
> > countries, regions ]
> > in my experience - It can be useful for finding local tagging errors.
> >
> >
> > dev site: http://taginfo-dev.opengeodata.hu
> > <http://taginfo-dev.opengeodata.hu/> find your area/country
> > 1 week test:   shutdown time: *~ 2018-aug-20 ( GMT 23:00h )*
> >
> >
> > Main changes:
> >
> > *-  620 areas  - not refreshing *
> >   = 620 docker services running in a simple cloud machine.
> > 32Gb RAM,   slow CPU :  Intel(R) Atom(TM) CPU
> > C2750  @ 2.40GHz,   8 core ,  ~ 600Gb Disk )
> >
> > *-  2 new experimental reports*:
> >
> >   "QA-Normalized name differences (Experimental)"
> > example:
> > http://eu-at.taginfo-dev.opengeodata.hu/reports/normalized_names
> > The result can be download as an xlsx file:
> > http://eu-at.taginfo-dev.opengeodata.hu/download/normalized_names.xlsx
> >
> > ( I hope - this will be useful for the localized
> > https://github.com/osmlab/name-suggestion-index
> >  ( see
> > https://github.com/osmlab/name-suggestion-index/issues/11 )
> >
> >
> >   "QA-Problematic tags (Experimental)" [ still a lot of bugs,
> >  for example:  checking access type of tags  is not perfect yet, sorry ]
> >  example:
> > http://eu-at.taginfo-dev.opengeodata.hu/reports/problematic_tags
> >  .xlsx result:
> > http://eu-at.taginfo-dev.opengeodata.hu/download/problematic_tags.xlsx
> >
> > *- `name` support for tags  ( Experimental ) *
> >
> >  examples:
> >  Spain   amenity=place_of_worship ( names in Spanish  + Català
> > (ca), Galego (ga) and Euskera (eu) )
> >  name   =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang1
> >  name:es  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang2
> >  name:eu  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang3
> >  name:ca  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang4
> >  name:gl   =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang5
> >
> >
> >or Switzerland   amenity=bank
> >  name   =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang1
> >  name:en  =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang2
> >  name:de  =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang3
> >  name:fr=
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang4
> >  name:it=
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang5
> >   the "name:*" tags configured on the
> > https://wiki.openstreetmap.org/wiki/Multilingual_names info but not
> > perfect yet.
> >
> >   so "Belgium has three official languages (Dutch, French and
> > German) "so the *amenity=pub * names is:
> >name =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang1
> >name:fr  =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang2
> >name:nl =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang3
> >name:en =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang4
> >name:de =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang5
> >  or in Ireland (Re

[OSM-talk] [test] Customized Taginfo : 620 areas - every country and some new experimental features ( ~ 1 week test )

[Imre Samu]

This is a Proof of Concept of my vision [ customizing taginfo for
countries, regions ]
in my experience - It can be useful for finding local tagging errors.


dev site: http://taginfo-dev.opengeodata.hu  find your area/country
1 week test:   shutdown time:  *~ 2018-aug-20 ( GMT 23:00h )*


Main changes:

*-  620 areas  - not refreshing *
  = 620 docker services running in a simple cloud machine.
32Gb RAM,   slow CPU :  Intel(R) Atom(TM) CPU  C2750  @
2.40GHz,   8 core ,  ~ 600Gb Disk )


*-  2 new experimental reports*:

  "QA-Normalized name differences (Experimental)"
example:
http://eu-at.taginfo-dev.opengeodata.hu/reports/normalized_names
The result can be download as an xlsx file:
http://eu-at.taginfo-dev.opengeodata.hu/download/normalized_names.xlsx

( I hope - this will be useful for the localized
https://github.com/osmlab/name-suggestion-index
 ( see
https://github.com/osmlab/name-suggestion-index/issues/11 )


  "QA-Problematic tags (Experimental)" [ still a lot of bugs,   for
example:  checking access type of tags  is not perfect yet, sorry ]
 example:
http://eu-at.taginfo-dev.opengeodata.hu/reports/problematic_tags
 .xlsx result:
http://eu-at.taginfo-dev.opengeodata.hu/download/problematic_tags.xlsx

*- `name` support for tags  ( Experimental )  *

 examples:

 Spain   amenity=place_of_worship ( names in Spanish  + Català
(ca), Galego (ga) and Euskera (eu) )
 name   =
http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang1
 name:es  =
http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang2
 name:eu  =
http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang3
 name:ca  =
http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang4
 name:gl   =
http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang5


   or Switzerland   amenity=bank
 name   =
http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang1
 name:en  =
http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang2
 name:de  =
http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang3
 name:fr=
http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang4
 name:it=
http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang5

  the "name:*" tags configured on the
https://wiki.openstreetmap.org/wiki/Multilingual_names info but not perfect
yet.

  so "Belgium has three official languages (Dutch, French and German)
"so the *amenity=pub * names is:
   name =
http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang1
   name:fr  =
http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang2
   name:nl =
http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang3
   name:en =
http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang4
   name:de =
http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang5

 or in Ireland (Republic )  -  amenity=pub  names  in a Gaeltacht
(name:ga)  :
http://eu-ie.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang3



  It is interesting for checking in your area the tag"names" of
*=yes  tags -  some of them easy to fix.
   * shop=yes  ;  amenity=yes   ;man_made=yes ; natural=yes
; sport=yes  ; leisure=yes

  amenity=yes  in the UK (
http://eu-gb.taginfo-dev.opengeodata.hu/tags/amenity=yes#tagnames_lang1 )
  shop=yes   in the UK (
http://eu-gb.taginfo-dev.opengeodata.hu/tags/shop=yes#tagnames_lang1 )


*Housenumbers ...*

 It is interesting for me - checking the frequent   * addr**:**housenumber *
 values.

 In Taiwan (
http://as-tw.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values )
not so much  number "4"
 compare to european countries ...   (  hint:
https://en.wikipedia.org/wiki/Tetraphobia )

 in Switzerland - check the 13   :)   (
https://en.wikipedia.org/wiki/Triskaidekaphobia )
  http://eu-ch.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values

The South America - has a different frequent housenumbers - compare to
Europe:

Argentina  :  TOP3   199,201,200 :
http://sa-ar.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values
Peru :   TOP3   100,200,199 :
http://sa-pe.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values
Brazil:   TOP3   100,50,35 :
http://sa-br.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values
Chile :   TOP3   500,600,401
http://sa-cl.taginfo-dev.opengeodata.hu/keys/addr:housenumber#values

in Europe:
DenmarkTOP3   4,3,5:
http://eu-dk.taginfo-dev.opengeodata.hu/keys/addr%3Ahousenumber#values
AustriaTOP3  1,3,2:

Re: [OSM-talk] Nominatim - censorship at github pages

[Imre Samu]

Hi Mariusz,

> I criticized that this important service is being neglected and is
maintained in a way which makes it quite impossible to contribute to.
>...
>Can somebody tell me why it is that?
> ...

imho:

my favorite on this topics:  https://en.wikipedia.org/wiki/
Nonviolent_Communication
and according to my experience  - moralistic judgments and diagnoses can't
help solve the problems.
on the other hand, Empathy ( for the project )  can be very powerful.

And If you want to understand the other side, read this:"Why I didn’t
fix your bug"   http://magnusmanske.de/wordpress/?p=518
so "Be nice" and give a positive surprise   ( for example add a picture of
a cute animal for your issue;   example:  https://github.com/moby/moby/
pull/36630 )

disclaimer:
- I have 1 accepted contributions:  https://github.com/openstreetmap/
Nominatim/pull/690


Regards,
 Imre


2018-03-26 12:43 GMT+02:00 cm-sani...@wp.pl :

> Hi,
> Some time ago on this mailing list I expressed concern about the way
> Nominatim is being maintained. In short, I criticized that this important
> service is being neglected and is maintained in a way which makes it quite
> impossible to contribute to. My opinion meet with hostility (which I don't
> really mind). But what I mind is censorship. Lately somebody else noticed
> [1] that having pull request opened for 6 years without any explanation why
> it's not merged doesn't look good. I contributed to the discussion,
> explained the reasoning for having it opened (which was presented to me
> during last time I took part in discussion here). Now I look at the pull
> request 's discussion and turns out my comment was removed.
>
> Can somebody tell me why it is that? In my opinion the fact I am not liked
> by the maintainers, shouldn't result in deleting my on topic comments. Is
> there some oversight over moderation? Can I somehow repeal the decision? Or
> at least get some explanation why my comment was removed?
>
> [1] - https://github.com/openstreetmap/Nominatim/pull/
> 27#issuecomment-370127296
>
> Thanks,
> Mariusz
>
> ___
> 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] Taginfo ( Africa, Central-America, Antarctica) - public testing ( for 2 weeks )

[Imre Samu]

I am testing dockerized small  "taginfo" instances ~ 120 country
"Taginfo is a system for finding and aggregating information about OSM tags
and making it browsable and searchable. It was created by Jochen Topf."

You can reach my testing site here: http://taginfo-dev.opengeodata.hu/
 for the next 2 weeks( after I will shut down )

About ~ 100 testing areas, some examples:

Berlin: http://eu-de-be.taginfo-dev.opengeodata.hu/
California: http://na-us-ca.taginfo-dev.opengeodata.hu/
Istanbul http://eu-tr-34.taginfo-dev.opengeodata.hu/

Burkina Faso : http://af-bf.taginfo-dev.opengeodata.hu/
Costa Rica : http://ca-cr.taginfo-dev.opengeodata.hu/
Cuba: http://ca-cu.taginfo-dev.opengeodata.hu/
Haiti: http://ca-ht.taginfo-dev.opengeodata.hu/
Kenya: http://af-ke.taginfo-dev.opengeodata.hu/
Madagascar: http://af-mg.taginfo-dev.opengeodata.hu/
Mali : http://af-ml.taginfo-dev.opengeodata.hu/
Nicaragua : http://ca-ni.taginfo-dev.opengeodata.hu/
Sri Lanka : http://as-lk.taginfo-dev.opengeodata.hu/
Tanzania: http://af-tz.taginfo-dev.opengeodata.hu/


daily refreshed: Africa,Central-America,Antarctica


I am also looking hosting/dev sponsors.

After 2 weeks - you can reach the latest info in the source code
repo : https://github.com/taginfo/dockerized-taginfo   ( issues, config
problems - Welcome! )

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

Re: [OSM-talk] Please do not re-use old node IDs

[Imre Samu]

Better test case is "node/1"  (
https://blog.openstreetmap.org/2015/12/25/openstreetmappy-christmas/ )
* https://www.openstreetmap.org/node/1/history


2018-03-06 11:26 GMT+01:00 Frederik Ramm :

> Hi,
>
> we're all concerned about the environment these days. "Reduce, Reuse,
> Recycle" is certainly something to strive for in the real world out there.
>
> However, for the second time now I've encountered a user who thought it
> was a good idea to reclaim old node IDs for new edits. A couple of
> long-deleted TIGER nodes were raised from the dead, and put to use in
> mapping some new roads on the other side of the planet.
>
> This sounds like a funny/quirky thing to do, and looks harmless enough
> on the surface. But anyone who ever looks at the history of things
> *will* be totally confused. Nobody who works with historic data will
> expect that a U.S. bus stop could become a tree in Romania. People are
> bound to interpret this in any number of wrong ways. It also messes up
> my full history extracts, where you'll now find the occasional German
> hiking route in the California data extract because a node that used to
> be in California is now part of a path that belongs to the hiking route.
>
> Long story short, please don't do it - let the API assign you new node
> IDs to your stuff instead of building ingenious contraptions to recycle
> old nodes.
>
> Thanks
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Imre Samu]

>What can I as a map editor do to keep these data files to a reasonable
size without compromising  data quality?

According to the "Lean thinking" (
https://en.wikipedia.org/wiki/Lean_thinking ) we should focus on
" eliminating waste"
Waste is:
*  Any polygon or  tagging errors ( because we can't use this information,
and need lot of space or processing resources )   or any from this:
https://wiki.openstreetmap.org/wiki/Error_categories ;  etc
*  or any mapping errors ( bad street names ;  routing problems: waste for
users   )
*  or any not "UpToDate" data/information  ( old phone numbers -   it is
useless,  so it is waste )

some examples:
http://area.jochentopf.com/stats/
- Errors: Intersections
- Errors: Duplicate nodes
- Errors: Duplicate segments (* ~160.000*)
- Errors: Open rings  ( ~9.000)
- Errors: Inner rings with same tags as outer rings
- Errors: Wrong role (  *~ 700.000 *)

some key problems:  ( unused/bad keys is a waste )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#problem
( Keys with possibly problematic characters )
- https://taginfo.openstreetmap.org/reports/characters_in_keys#space
 ( Keys with whitespace )
- or my favorite:
---  https://taginfo.openstreetmap.org/keys/latitude#values
---  https://taginfo.openstreetmap.org/keys/LAT#values

And we have lot of low quality imports we should fix.

>What can I as a map editor

imho:
Any quality assurance work helps a lot:
https://wiki.openstreetmap.org/wiki/Quality_assurance
so fixing data problems in your area helps "eliminating waste"and  less
waste is good for data size


Imre



2018-01-18 6:14 GMT+01:00 Oleksiy Muzalyev :

> Good morning,
>
> I started to experiment with the OSM data [1] on a local computer, and I
> begin to realize how big these data files are. It takes quite a while to
> load into the local database just the data for one country.
>
> What can I as a map editor do to keep these data files to a reasonable
> size without compromising  data quality? I mean in the sense, - take care
> of the pennies and the pounds will take care of themselves?
>
> I could think of the following three approaches so far:
>
> - using as short an URL as possible, website=http://somewebsite.com
> instead of website=http://www.somewebsite.com , three characters less; [2]
>
> - correct phone number ISO format, phone=+12 345 678 90 12 instead of
> phone=+12 (345) 678 90 12 , two characters less;  [3]
>
> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with consequent
> verification of its geometry;
>
> What else, if anything, could be done?
>
> [1] https://wiki.openstreetmap.org/wiki/Downloading_data
> [2] https://wiki.openstreetmap.org/wiki/Key:website
> [3] https://wiki.openstreetmap.org/wiki/Key:phone
>
> With best regards,
> Oleksiy
> osm: Alex-7
>
> ___
> 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] How to teach novices about optimal changeset size?

[Imre Samu]

>  one changeset per building, repeated 20 times

my typical use case:   House numbering on the street:  push the numbers &
forget & go to the next house( fast feedback loop vs. Delayed
gratification  )
- sometimes the mobil app is crashing, and I don't want to go back 100m to
re-enter - the last 5-10 numbers

> Obviously this makes them PITA to review quickly in Achavi or whatever
tool you use.

imho: it is easier to group the changeset on the reviewer side :  by user +
by hour   ( group by user, hour )   than change the community.

Imre





2018-01-17 15:13 GMT+01:00 Michał Brzozowski :

> Certainly not:
> - one changeset per building, repeated 20 times
> - one changeset for 3 POIs that are 1000 km apart in different countries
>
> These are real world examples. In the latter Achavi can often refuse to
> run.
>
> That's also why I asked ;-) It's not that easy to formulate the answer
> what is reasonable to include in a changeset.
>
> Michał
>
> 17.01.2018 2:54 PM "Tobias Zwick"  napisał(a):
>
>> So, what is the optimal changeset size, and why?
>>
>> Tobias
>>
>> On 17/01/2018 14:26, Michał Brzozowski wrote:
>> > Many new users have a habit of e.g. sending one or few objects per
>> > changeset, resulting in a dozen or even more changesets per day.
>> > Obviously this makes them PITA to review quickly in Achavi or whatever
>> > tool you use.
>> >
>> > This habit is probably caused by non-knowledge of how auto-save works in
>> > iD (which makes the work reasonably secure), as well as just not knowing
>> > better thus forming their own judgement.
>> >
>> > How should we teach about optimal changeset size? This is quite tricky -
>> > how we would define it?
>> >
>> > Can the iD nudge users towards better practice? (Linking to Good
>> > changeset comments wiki page would be useful as well)
>> >
>> > Michał
>> >
>> >
>> > ___
>> > 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] Length of ways

[Imre Samu]

For a batch solution:
* Pyosmium has an osm "road length" example:
https://github.com/osmcode/pyosmium/blob/master/examples/road_length.py


2017-12-01 1:15 GMT+01:00 Andy Mabbett :

> Do we have a tool that will give me the length of a way (or a
> relation, made from several continuous ways)?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Adding wikidata tags to the remaining objects with only wikipedia tag

[Imre Samu]

> I hope everyone realizes that there are Wikidata items for which there
> is no Wikipedia article.
> So you cannot always find it via Wikipedia  tags.
>  And at least JOSM shows a human readable name of a Wikidata item
> besides the Q-number. I think iD does this as well.
> m. (who manually adds Wikidata references for Flemish churches after
creating the Wikidata items).

imho:
probably you have a local and domain knowledge on the topic of "Flemish
churches"
but for me:  wikidata without wikipedia page - is  extremely suspicious

because:

#1.  Sometimes the " nearby" search for geolocated articles/wikidataids is
not enough
for example:
* at least ~28000 churches exist in the wikidata without coordinates:
http://tinyurl.com/y8nyk9zw

And probably we will also find wikidata cities without coordinates.

#2. And we should aware of the current "Parallel geo worlds" problem in the
wikidata[1]
for example:
Arad ( major City in Romania ) has 3 wikidata, and we should prefer id with
wikipedia pages.
* https://www.wikidata.org/wiki/Q173591 ( with wikipedia pages, linked to
OSM )
* https://www.wikidata.org/wiki/Q31886684 (  created by Cebuano import [1]
   ~1 month ago) * https://www.wikidata.org/wiki/Q16898082

[1] wikidata cebuano import problem:
* https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/
2017/08#Dealing_with_our_second_planet * https://www.wikidata.org/wiki/
Wikidata:Project_chat/Archive/2017/08#Nonsense_imported_from_Geonames


Imre






2017-09-27 5:03 GMT+02:00 Marc Gemis :

> On Wed, Sep 27, 2017 at 1:17 AM, Andy Townsend  wrote:
> > That's simply rubbish.  Tags on an OSM object describe it in the real
> world.
> > They should be verifiable.  Whether an OSM object has a wikidata tag on
> it
> > is essentially irrelevant as far as OSM is concerned - it's just a
> primary
> > key into an external database.  External data consumers might find the
> data
> > in that database useful, but they can also get to it via wikipedia tags
> > (which, being human-readable, are more likely to be maintained), so it's
> > really not a big deal.
>
>
> I hope everyone realizes that there are Wikidata items for which there
> is no Wikipedia article. So you cannot always find it via Wikipedia
> tags.
>
> And at least JOSM shows a human readable name of a Wikidata item
> besides the Q-number. I think iD does this as well.
>
> m. (who manually adds Wikidata references for Flemish churches after
> creating the Wikidata items).
>
> ___
> 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] Label language on the Default stylesheet

[Imre Samu]

>That sounds like an argument against any incremental improvement ever

imho: the risk Identification is an important design step.  [
https://en.wikipedia.org/wiki/Risk_management ]
And reducing risks is another step.



2017-09-25 16:34 GMT+02:00 Nicolás Alvarez <nicolas.alva...@gmail.com>:

>
> El 25 sept 2017, a las 10:54, Imre Samu <pella.s...@gmail.com> escribió:.
>
>
> What about the other alternatives?
>
> for example:
> - just adding ALL (official[1])  dual languages for only Z0-Z8 level, and
> keeping the current design for Z9-Z19
>
> so there will be  (z0-z8)
> - local + english
> - local + chinese
> - local + arabic
> - local + japanese
> - local + russian
> - local + german
> - local + spanish
> - ...
> - local + greek
> - local + hungarian
> - local + 
> - .
>
>
> This is 262144 more tiles *per language*. Who wants to donate a few disks?
>
>
> And the other question:   Adding the English language now  - can be
> counterproductive for implementing the full multi-language support?   (
> for example - less urgency?)
>
>
> That sounds like an argument against any incremental improvement ever.
> Wouldn't your proposed multilingual tiles cause less urgency for vector
> tiles too?
>
> Imre
> /native Hungarian/
>
>
>
> 2017-09-25 13:48 GMT+02:00 Matthijs Melissen <i...@matthijsmelissen.nl>:
>
>> On 25 September 2017 at 13:21, Richard Fairhurst <rich...@systemed.net>
>> wrote:
>> > Frederik Ramm wrote:
>> >> I'd invest the available brainpower in steps needed to achieve
>> >> this goal, even if it's a year or two in the future.
>> >
>> > Which means vector tiles... which we should be looking at anyway.
>> >
>> > But that needs to be a separate project really, rather than a facet of
>> > openstreetmap-carto.
>>
>> Yes, to re-iterate: my question is about things we can do now. Vector
>> tiles are on the horizon, but are likely to take a year or more from
>> now. Changing some of the labels is something we could do with one
>> line of code and roll out tomorrow, if we wanted to.
>>
>> -- Matthijs
>>
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Label language on the Default stylesheet

[Imre Samu]

>Yes, to re-iterate: my question is about things we can do now. Vector
>tiles are on the horizon, but are likely to take a year or more from
>now. Changing some of the labels is something we could do with one
>line of code and roll out tomorrow, if we wanted to.

What about the other alternatives?

for example:
- just adding ALL (official[1])  dual languages for only Z0-Z8 level, and
keeping the current design for Z9-Z19

so there will be  (z0-z8)
- local + english
- local + chinese
- local + arabic
- local + japanese
- local + russian
- local + german
- local + spanish
- ...
- local + greek
- local + hungarian
- local + 
- .

[1]  https://en.wikipedia.org/wiki/List_of_official_languages

For the small languages, it will be useful for fixing data problems early,
and IMHO a better transition for a full multi-language support.


>The openstreetmap-carto team quite frequently receives requests to  
>(additionally)
display labels in English
> (or in any case the Latin-alphabet)

We must remember the survivorship bias [
https://en.wikipedia.org/wiki/Survivorship_bias ]
People who can't speak English - can't complain in the English forum.  (
lack of visibility )

And the other question:   Adding the English language now  - can be
counterproductive for implementing the full multi-language support?   ( for
example - less urgency?)

Imre
/native Hungarian/



2017-09-25 13:48 GMT+02:00 Matthijs Melissen :

> On 25 September 2017 at 13:21, Richard Fairhurst 
> wrote:
> > Frederik Ramm wrote:
> >> I'd invest the available brainpower in steps needed to achieve
> >> this goal, even if it's a year or two in the future.
> >
> > Which means vector tiles... which we should be looking at anyway.
> >
> > But that needs to be a separate project really, rather than a facet of
> > openstreetmap-carto.
>
> Yes, to re-iterate: my question is about things we can do now. Vector
> tiles are on the horizon, but are likely to take a year or more from
> now. Changing some of the labels is something we could do with one
> line of code and roll out tomorrow, if we wanted to.
>
> -- Matthijs
>
> ___
> 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] Wikipedia/Wikidata admins cleanup

[Imre Samu]

>..  this coordinates correction ...  Before this correction it had wrong
coordinates placing it erroneously on absolutely another mountain. ...

As I see there is a tool for detect distance differences :

*OpenStreetMap - Wikidata Validator*
Each circle is an OpenStreetMap feature with a Wikidata tag.
Circle size and color are based on the distance in kilometers between
OpenStreetMap feature and Wikidata coordinates.
Large red circles mean the distance is greater than 10 kilometers, which
indicates a higher error rate.


map:  https://osmlab.github.io/wikidata-osm
code: https://github.com/osmlab/wikidata-osm  ( first commit:  Nov 25, 2016
)
issues: https://github.com/osmlab/wikidata-osm/issues



2017-01-04 11:21 GMT+01:00 Oleksiy Muzalyev :

> Certainly a tool to check and correct obviously broken or duplicate
> wikipedia=*, wikimedia_commons=*, wikidata=* links from the OSM map would
> be very useful.
>
> However, I've met inconsistencies which could be noticed only by a
> knowledgeable human on the ground. For example, this coordinates
> correction
> 
> for the chapel Chapelle Notre-Dame-des-Voirons de Boëge
> 
> . Before this correction it had wrong coordinates placing it erroneously on
> absolutely another mountain. I could correct it reliably only after
> actually visiting this chapel for making some photos for its article.
>
> The comprehensive solution would be to have a dedicated Wikipedia layer on
> the OpenStreetMap. Now we have Standard, Cycle, Transport, and Humanitarian
> layers. Why not Wikipedia layer similar to this
> 
> , so that a user can select Wikipedia language and see the geo-markers
> corresponding to Wikipedia articles on the map. Or see clickable
> geo-markers corresponding to wikipedia=*, wikimedia_commons=*, wikidata=*
> tags.
>
> This tool is using MediaWIki API and Overpass API, but for the OSM
> Wikipedia layer the data could be pre-calculated and synchronized
> periodically in order not to overload the APIs.
>
> In fact, I am using the OSM map mostly with Wikipedia markers. For
> example, I was recently on a short holiday trip to Stockholm and the first
> thing I do I look what Wikipedia articles exist for the city
> 
> to select places to visit and to read about. So in my opinion, such a
> Wikipedia layer would be kind of synergy, - the creation of a whole that is
> greater than the simple sum of its parts.
>
> Best regards,
> Oleksiy
>
>
> On 04.01.17 10:27, Jorge Gustavo Rocha wrote:
>
> Hi Yurik,
>
> Nice work.
> I'm interested in make such validation a service, to identify and fix any
> inconsistencies between OpenStreetMap and Wikipedia/Wikidata.
> I'll be working on that on the next days.
>
> Regards,
>
> J. Gustavo
>
> Às 09:11 de 03-01-2017, Yuri Astrakhan escreveu:
>
> I have been steadily cleaning up some (many) broken Wikipedia and
> Wikidata tags, and would like to solicit some help :)
>
> To my knowledge, there is no site where one could add a set of OSM IDs
> that need attention (something like a bug tracker lite, where one could
> come and randomly pick a few IDs to fix), so I made a few tables:
>
> List of Wikipedia tags that do not resolve to Wikidata tags. Most of the
> time, the WP tag is incorrect, sometimes it was deleted, and very rarely
> there is no matching Wikidata item (needs to be created by hand).
> * https://www.mediawiki.org/wiki/User:Yurik/OSM_NoWD
>
> List of duplicate Wikidata tags:
> * https://www.mediawiki.org/wiki/User:Yurik/OSM_duplicates2
>
> Thanks!
>
>
> ___
> 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] Working with lat and long simply

[Imre Samu]

>...nominatim ...
>It is currently inconsistent, and that's a problem for those without a PhD
in GIS.

If you have a suggestions ->  Nominatim issues:
https://github.com/twain47/Nominatim/issues


2016-09-10 21:34 GMT+02:00 john whelan :

> The issue isn't that nomination won't handle lat and long it is that you
> cannot cut and paste from the xml code.  "lat='45.472891'
> lon='-75.4891002'" doesn't work.  You have to know enough or have the
> instructions to hand to strip off the unwanted lat= and lon=.
>
> It is currently inconsistent, and that's a problem for those without a PhD
> in GIS.  One solution could be a write up in the wiki.
>
> Cheerio John
>
> On 10 September 2016 at 15:27, michael spreng 
> wrote:
>
>> On 10/09/16 17:43, john whelan wrote:
>> > However dig it out of the xml code and drop it into Nomination and you
>> > get an error.  lat='45.472891' lon='-75.4891002'
>> What kind of error do you get? Works for me:
>> http://nominatim.openstreetmap.org/search.php?q=45.4729+-75.4891
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> ___
> 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] Osmose, duplicate housenumber

[Imre Samu]

>Osmose seems to follow the rule: One feature, one OSM element (or one
feature, one tag) and avoids duplicating data.

imho=yes

#1.
in Hungary - we don't have housenumber imports  ..  so all housenumber
collected by mappers.   And sometimes exist in the building - and most of
the times not.
And it is very hard to communicate that some shops allowed the
 "addr:housenumber"  - and others not.

imho :
- this rule  is not beginner friendly.


#2.
As I know, the iD Editor is not following this rule ..
And the "contact:housenumber"  is not used by projects ( = editors )
http://taginfo.openstreetmap.org/keys/contact%3Ahousenumber#projects

Probably we need to add the  "addr:housenumber"  to the exception list [1]
because  this "practice is firmly established and unlikely to change. "
[1]  http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


Imre


2016-06-01 10:16 GMT+02:00 althio :

>
>
> Łukasz Stelmach
>
>>
>> Can you explain why Osmose (and does it matter at all) warns about
>> duplicate housnumber when a shop (node) with a set of addr:* tags is
>> created inside a building (area) that is also tagged with addr:*?
>
>
>
> Osmose seems to follow the rule: One feature, one OSM element (or one
> feature, one tag) and avoids duplicating data.
>
> The rationale is certainly close to:
> http://wiki.openstreetmap.org/wiki/House_numbers/Bremen_Schema
>
> where you can use:
>  - addr:* tags for buildings or nodes on the street
>  - contact:* tags for contact information about a POI
>
> Best,
>
> -- althio
>
> ___
> 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] BBC License Violation?

[Imre Samu]

 BBC
 source NGA, Nepalese government

??
http://nepal.nga.opendata.arcgis.com/datasets/74deb0f5eb6f4f7099f8f24cc176d5f9_3

IDP Camps Nepal April 29th 2015
- IDP_Camps (2111)
- Production : 04/28/2015 to 04/29/2015
- Metadata IDP Camps Nepal April 29th 2015
- Licensing No license specified
- Source
http://ngamaps.geointapps.org/arcgis/rest/services/NEPAL/Latest_NGA_Damage_Assessments/MapServer/3


and , maybe related :
Nepal, OSM License, and the NGA
http://www.openstreetmap.org/user/MapMakinMeyers/diary/34878


Imre


2015-05-01 23:53 GMT+02:00 Robert Banick rban...@gmail.com:

 This: http://www.bbc.com/news/world-asia-32551499

 Map at bottom

 —
 Sent from Mailbox https://www.dropbox.com/mailbox


 On Fri, May 1, 2015 at 9:50 PM, Pierre Béland pierz...@yahoo.fr wrote:

 same problem with me.


 Pierre

  --
 *De :* Simon Poole si...@poole.ch
 *À :* talk@openstreetmap.org
 *Envoyé le :* Vendredi 1 mai 2015 17h44
 *Objet :* Re: [OSM-talk] BBC License Violation?

 Robert, the link doesn't seem to work (not just for me)

 Simon





 ___
 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] Chain Store Cleanup

[Imre Samu]

 .. McDonald's  problem...

Please don't forget the   true McDonald's problem!  It is a content
encoding hell.
and very hard to detect by any ordinary field mappers.

  #1.
name=McDonald’s( count=126 )  U+2019 ’ e2 80 99 RIGHT SINGLE
QUOTATION MARK
http://taginfo.openstreetmap.org/tags/name=McDonald%E2%80%99s
http://overpass-turbo.eu/s/97c

 #2.
name=McDonald´s( count=40 )   U+00B4 ´ c2 b4 ACUTE ACCENT
http://taginfo.openstreetmap.org/tags/name=McDonald%C2%B4s
http://overpass-turbo.eu/s/97e

 #3.
name=McDonald's   ( count=14039)   U+0027 ' 27 APOSTROPHE
http://taginfo.openstreetmap.org/tags/name=McDonald's

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

Re: [OSM-talk] Chain Store Cleanup

[Imre Samu]

 cleaning up incorrect chain store data in OSM.
...  McDonald's fast food restaurant,  ...


related project:   https://github.com/osmlab/name-suggestion-index
and iD Editor use this (
https://github.com/openstreetmap/iD/blob/master/data/name-suggestions.json )

and don't forget internationalisation :


like:
Макдоналдс: { count: 324, tags: { name:en: McDonald's } マクドナルド:
{ count: 692, tags: { name:en: McDonald's, cuisine: burger }

Regards,
 Imre



2015-05-01 0:04 GMT+02:00 Andrew MacKinnon andrew...@gmail.com:

 I am trying to figure out a way of cleaning up incorrect chain store
 data in OSM. For example there are 1422 instances of McDonalds in
 OSM (should be McDonald's) and 203 instances of Tim Horton's (should
 be Tim Hortons).

 I have created pages on the OSM wiki called
 http://wiki.openstreetmap.org/wiki/Chain_Store_Cleanup and
 http://wiki.openstreetmap.org/wiki/Chain_Store_Directory. Ideally I
 would like to create wiki pages for every large chain of stores in the
 world that is similar to Map Features, with recommended ways of
 tagging chain stores. A lot of new OSM users get this wrong and create
 incorrect data, and there wasn't anything on the wiki telling users
 that McDonalds or Tim Horton's is incorrect. This is really
 preliminary and I'm sure that this can be improved a great deal. I
 would also like to keep track of chain stores that have closed stores
 or changed name. For example, Target closed all its stores in Canada
 recently and Wal-Mart changed the name of all its stores to Walmart a
 few years ago.

 Do people mind if I start fixing these errors myself, finding POIs
 with overpass turbo and editing individual POIs one at a time? I
 understand that large scale mechanical edits over a large area are a
 bad idea and the admins hate people doing that (it is too easy to make
 mistakes, and there is bound to be something called McDonalds that
 is not actually a McDonald's fast food restaurant, and I don't really
 want to get into wars over how to tag things, but amenity=fast_food
 and name=McDonalds is just wrong). I think that applying the
 mechanical edit policy to semi-automated edits that are done one at
 a time is overkill though. However, there are a lot of these errors in
 OSM, so I really need help from other people to fix these errors.
 Also, it would be appreciated if validation rules for chain stores
 could be added to automated bug fixers such as maproulette, keepright,
 osmose, etc.

 ___
 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] this has to stop: iD user mistakes all over the place

[Imre Samu]

has only 35 rows.

17 word pair +  1 header record

There are other worksheets ,  you can switch/change  at the bottom of the
page:

Direct links:

*meta_pl : meta data ...*
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=2147407685

*iDups,-  duplicated/same translations  ( 34  rows )*
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312

*iPresets,-   presets  ( 2028  rows )*
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1125791958

*iFields  -fields (261 rows  )  *
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=661789118
Imre



2015-02-13 11:54 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com:


 https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312
 has only 35 rows.

 2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com:

 There's one more face to iD and mistakes users make: translations.
 Bad translations cause bad tagging.
  Example: track was translated to Polish .

 Good translation is very important for the beginners.
 and _now_  not so easy to check the quality of the iD translations.

 I would like to inform you, that I am working on a new *iD Editor
 translation QA tool *
for helping translators  detecting  translator bugs ...



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

Re: [OSM-talk] this has to stop: iD user mistakes all over the place

[Imre Samu]

There's one more face to iD and mistakes users make: translations.
Bad translations cause bad tagging.
 Example: track was translated to Polish .

Good translation is very important for the beginners.
and _now_  not so easy to check the quality of the iD translations.

I would like to inform you, that I am working on a new *iD Editor
translation QA tool *
   for helping translators  detecting  translator bugs ...

I have created an experimental, manually formatted QA metadata reports for
Polish language :)
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312

Maybe you can use.
 (   4 Sheets :
-  meta_pl : meta data ...
-  iDups,-  duplicated/same translations
-  iPresets,-   presets  ( 2028  )
[ translations from transifex +  presets.json
https://github.com/openstreetmap/iD/blob/master/data/presets/presets.json
 ]
-   iFields  -fields (261 )
 [translations from transifex + fields.json
https://github.com/openstreetmap/iD/blob/master/data/presets/fields.json ]
  )


Freshly generated raw reports exists  for every other  iD languages (
de,pl,es,ru, cz,pt,  ... ) ( but not formated )
   see  :   https://github.com/ImreSamu/ideditor_translation_test_reports

   find  your xlsx - ./qadata/
(LangCode)/id_presets_translation_(LangCode).xlsx
   for example:

./qadata/af/id_presets_translation_af.xlsx
./qadata/ar/id_presets_translation_ar.xlsx
./qadata/ar-AA/id_presets_translation_ar-AA.xlsx
./qadata/ast/id_presets_translation_ast.xlsx
./qadata/bg-BG/id_presets_translation_bg-BG.xlsx
./qadata/bn/id_presets_translation_bn.xlsx
./qadata/bs/id_presets_translation_bs.xlsx
./qadata/ca/id_presets_translation_ca.xlsx
./qadata/cs/id_presets_translation_cs.xlsx
./qadata/da/id_presets_translation_da.xlsx
./qadata/de/id_presets_translation_de.xlsx
...



My favorite problems type is the same/duplicated translations
(  https://github.com/openstreetmap/iD/issues/2448 )
Now the status by languages  -here : id_langDups_all.md
https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langDups_all.md


For example German language.
But be careful,  Experimental report!
Not every  line is problematic -  please check  the other columns
 like
  - geometry metadata  (
area,point,line,vertex,relation )
  - searchable
   (  id_presets_translation_duplicates_de.md
https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/de/id_presets_translation_duplicates_de.md
)   nameTransl nameEn presetKey  Administrative Grenze Administrative
Boundary type/boundary/administrative  Administrative Grenze Administrative
Boundary boundary/administrative  Bahnsteig Platform
public_transport/platform  Bahnsteig Railway Platform railway/platform
Boutique Boutique shop/boutique  Boutique Fabric Store shop/fabric
Campingplatz Camp Site tourism/camp_site  Campingplatz RV Park
tourism/caravan_site  Drogerie Chemist shop/chemist  Drogerie Cosmetics
Store shop/cosmetics  Eisenbahn Rail railway/rail  Eisenbahn Railway railway
Fährenroute Ferry Route route/ferry  Fährenroute Ferry Route
type/route/ferry  Friedhof Graveyard amenity/grave_yard  Friedhof Cemetery
landuse/cemetery  Garagen Garages building/garages  Garagen Garages
landuse/garages  Gemischtwarenhandel Convenience Store shop/convenience
Gemischtwarenhandel Variety Store shop/variety_store  Graben Ditch
barrier/ditch  Graben Ditch waterway/ditch  Hütte Hut building/hut  Hütte
Cabin building/cabin  Kehrtwendeverbot No Turns
type/restriction/only_straight_on  Kehrtwendeverbot No U-turn
type/restriction/no_u_turn  Kirche Church amenity/place_of_worship/christian
Kirche Church building/church  Radweg Cycle Path highway/cycleway  Radweg Cycle
Route type/route/bicycle  Seilbahn Cable Car aerialway/cable_car  Seilbahn
Aerialway aerialway  Uhrmacher Clockmaker craft/clockmaker  Uhrmacher
Watchmaker craft/watchmaker  Wald Wood natural/wood  Wald Forest
landuse/forest  Zebrastreifen Crosswalk footway/crosswalk  Zebrastreifen
Crosswalk highway/crosswalk

And the Translation status by languages :  id_langData_all.md
https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langData_all.md



Imre
   ( from the Hungarian OSM community )



2015-02-13 3:43 GMT+01:00 Michał Brzozowski www.ha...@gmail.com:

 Whoops. Good to know. Though it's still rudimentary ;) Not long ago I
 tried to do intentionally do stupid things in iD demo in order to see
 if it would stop me - it didn't.

 There's one more face to iD and mistakes users make: translations. Bad
 translations cause bad tagging. English terms don't always translate
 1:1 so I think it is beneficial for a translator to deviate a little
 when needed. Example: track was translated to Polish as droga
 gruntowa (grunt is ground so translated 

Re: [OSM-talk] Data filter

[Imre Samu]

How can I select ‘my contributions in UK’ and output as XML (or JSON?).
Need a file that can be imported in to standard GIS packages.

Hi Steve,

*--- hard way *

see http://wiki.openstreetmap.org/wiki/Planet.osm/full  and filter data
with your user id.

#1  download full history
pbf: http://planet.openstreetmap.org/pbf/full-history/
(42Gb  !!! )
xml: http://planet.openstreetmap.org/planet/full-history/(59Gb)

#2  cut  area  with osm-history-splitter , smaller the better  ( UK )
 https://github.com/MaZderMind/osm-history-splitter

[ there are some history extracts but no UK ,
http://osm.personalwerk.de/full-history-extracts/2014-11-24/
but you can test your workflow with nepal.osh.pbf ( it is only 23M
) ]

#3. Load to PostgreSQL database  with osm-history-importer
  https://github.com/MaZderMind/osm-history-renderer

#4. Filter PostgreSQL data ( hist_point ; hist_line ; hist_polygon ) with
your user_name
   schema:

https://github.com/MaZderMind/osm-history-renderer/blob/master/importer/scheme/00-before.sql


alternative solution:
-  using osmium library and write  a simple code to
-  filter OSM history data with your user_id
   ( with pyosmium   [ ptyhon library   :
https://github.com/osmcode/pyosmium  ]
 or with  node-osmium [ Javascript library :
https://github.com/osmcode/node-osmium ]

Cheers,
  Imre


2015-01-12 10:30 GMT+01:00 Steve Chilton s.l.chil...@mdx.ac.uk:

 Can anyone help me with filtering OSM data please?

 For a project I am working on I need data on my contributions to the
 project.

 How can I select ‘my contributions in UK’ and output as XML (or JSON?).

 Need a file that can be imported in to standard GIS packages.

 Any help gratefully received.



 Cheers

 Steve



 Steve Chilton FSEDA, Teaching Fellow

 Lead Academic Developer

 Centre for Academic Practice Enhancement (CAPE)

 Middlesex University

 phone: 020 8411 5355

 email: ste...@mdx.ac.uk

 Profile: http://www.middlesex.wikispaces.net/user/view/steve8



 Blog: http://itsahill.wordpress.com/

 Chair of the Society of Cartographers: http://www.soc.org.uk/

 Chair of ICA Neocartography Commission: http://neocartography.icaci.org/



 *[image: MDX LOGO]*




 *
 ---
 *

 *Please note that Middlesex University's preferred way of receiving all 
 correspondence is via email in line with our Environmental Policy.   All 
 incoming post to Middlesex University is opened and scanned by our digital 
 document handler, CDS, and then emailed to the recipient.

 If you do not want your correspondence to Middlesex University processed in 
 this way please email the recipient directly. Parcels, couriered items and 
 recorded delivery items will not be opened or scanned by CDS.  There are 
 items which are exceptions which will be opened by CDS but will not be 
 scanned a full list of these can be obtained by contacting the University.
 *


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


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

Re: [OSM-talk] OSM France BANO project... openaddresses in France

[Imre Samu]

Hi Christian,

As I read OKFN article [1]  about BANO project ( November 17, 2014 )
It's not perfectly clear to me what it is the BANO license ?  ( only ODBL
or Dual licensed  ?   )

from the text [1]  :
Q:The reached agreement includes a dual license framework. You can reuse
the data for free under an ODbL license,
 or you can opt for a non-share-alike license but you have to pay a
fee.  Is share-alike clause an obstacle for the private sector?
 .
 

[1]
http://blog.okfn.org/2014/11/17/an-unprecedented-public-commons-partnership-for-the-french-national-address-database/

regards,
 Imre



2014-05-24 17:02 GMT+02:00 Peter Wendorff wendo...@uni-paderborn.de:

 Hi Christian,
 (shortening the last message to comment on some parts only)

 Am 24.05.2014 16:04, schrieb Christian Quest:

  BANO is not designed to be used as an import source for OSM.
  It uses sources (opendata, cadastre) that can be imported in OSM.
  These sources have been used over the past years and will still be used
 to
  add addresses in OSM, one at a time, or street by street which will take
  years before completion.
 
  So, BANO is there to allow to use all the available address data right
 now
  without having to wait years to get them cleanly added to OSM.
 I agree - but why should anybody add the data manually to osm if it's
 even not visible any more where data is missing, as in Nominatim both
 sources look the same.

  This has one good side effect... reduce the pressure on massive address
  imports in OSM and give us the opportunity to improve the quality thru
  survey prior to add it to OSM.
 I agree if you propose BANO as a data source for any private or third
 party setup of nominatim or openstreetmap data, but I oppose it to be
 used in the projects instances.

 Mappers detect errors and missing data while using these instances. I
 add missing streets occasionally after I failed to find them in OSM -
 using the map renderings, nominatim or other tools.
 I wouldn't even detect that they are missing when nominatim would return
 the results from another source.

  2014-05-24 12:58 GMT+02:00 Peter Wendorff wendo...@uni-paderborn.de:
  Adding it to (the osm installation of) nominatim on the other hand is a
  bad idea, I think:
  IMHO nominatim.openstreetmap.or should rely on OSM as a data source as
  pure as possible. Adding different data sets might be useful to add
  information not possible or out of scope of the osm database (like
  importance factors using the wikipedia links), but BANO is a different
  thing.
 
  If the BANO addresses are free and open enough for OSM, we should
  encourage to work on bringing them to the OSM database itself (provided,
  they are GOOD enough as well). How should anybody in France get
  motivation to collect more addresses for the osm database itself, if
  anything is available in BANO already?
 
 
  I'm pushing the french community to be more motivated on having all
 streets
  and all streets name in OSM (BANO allowed us to detect 40% missing
 streets
  or street names) more than adding addresses without surveying them.
 Great - but I fear, the availability of third data sources like BANO
 through the usual tools destroys motivation again, the motivation get's
 an extrinsic one, because the intrinsic need of mappers to get rid of
 errors and missing results using OSM is missing due to results returned
 out of the BANO data.

  I agree to motivate to collect BETTER address data... it we collect the
  same data with the same quality level it looks to me more losing our time
  than anything else.
 Mappers are better than you might think.
 Collecting the same data with the same quality level is not possible.
 1) the data is checked in reality = so survey on the ground increases
 quality with respect to errors.
 2) the data is correct at the date of the survey = where it is done
 it's more up to date than any imported data, but of course only where it
 is done.
 3) When a mapper goes out to add streets and house numbers, it's easy to
 collect any other stuff where there is no other data source available.
 post boxes, benches, vending machines, opening hours, surface of the
 streets and much more stuff that increases quality. In contrast
 importing data is restricted to the data contained in the data source.

  P.S: Of course this is not meant to deal with the software as such, but
  for the installations/instances officially part of OSM. Feel free to
  set up an BANO nominatim server to show the strength of BANO instead.
 
  In that case remove geonames and TIGER address search from
  osm.org Nominatim instance.

 On osm.org Genonames is a different search result set, distinct from
 Nominatim, there are two different query results returned.
 This is a good way to go, and yes, it might an idea to do the same with
 BANO - but that's not what you proposed: it's not adding the BANO data
 to Nominatim.

 regards
 Peter

 ___
 talk mailing list
 

Re: [OSM-talk] OSM completeness

[Imre Samu]

 completeness of the road datasets in OSM.

if you are interested the Street(=road) name comparision
- check this local projects:

#OSM Housenumber Evaluation ( with street names )  :
https://www.sotm-eu.org/slides/58.pdf ( video:
https://www.sotm-eu.org/en/slots/50 )
http://regio-osm.de/hausnummerauswertung/auswertung_auswahlort
(Germany, Austria, Iceland, Romania, Luxemburg,.. )

#Hungary : Street name completeness statistics :  http://82.196.14.91/  (
my development )

#Switzerland : http://qa.poole.ch/ch-roads/
http://wiki.openstreetmap.org/wiki/OSM_-_GWR_Street_and_Place_Names_Comparison

#UK  -
 Completeness analysis and ranking of UK councils by ITO World comparing OS
Locator data.
 http://wiki.openstreetmap.org/wiki/OSM_and_OSL_differences_analysis
 http://www.itoworld.com/product/data/osm_analysis/main

Imre



2014-09-02 14:29 GMT+02:00 Eleanor Stokes eleanor.sto...@yale.edu:

 Hi list,
 Not sure if this is the right place to post--but I just got into using OSM
 and
 am hoping to utilize it for some of my research.  I need to get some kind
 of
 completeness metric for each of the cities I am looking at (about 200 of
 them).

 Does anyone happen to know of completeness analyses
 across cities in different regions that have been performed?
 I'm particularly interested in the completeness of the
 road datasets in OSM.



 ___
 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] need advice for clever query or script

[Imre Samu]

Hi Richard,

 clever query or script

maybe you can use OSM OPL format this ad-hoc query,
and process the data  with sed, awk, grep .

my draft ubuntu script - with comments.

https://gist.github.com/ImreSamu/be49fd1ce511975325d2#file-bridge_swing-sh

result (  Overpass-Wizard Query - but you can export the data to JOSM   )

https://gist.github.com/ImreSamu/a2dd0a8c25f0fea5284c#file-bridge_swing_overpass_wizard-md


the example result - Overpass-Wizard Query :

type:way and ( id:28134411 or id:29295367 or id:30178341 or id:30178382 or
id:33132931 or id:33132936 or id:33132949 ) global


( http://wiki.openstreetmap.org/wiki/Overpass_turbo/Wizard - see
Meta-Data Filters )

*How to check the query *

** go  http://overpass-turbo.eu/ http://overpass-turbo.eu/ *
** select Wizard*
* * copy /paste the generated query :   type:way and ( id:27001207 or
id:72584563 )  global*
* * Build and run query - and check the result.*
* * if you got timeout error, then check the generated script timeout (
osm-script output=json timeout=25 )  and set to 200 - and rerun  *
** you can load data into an OSM editor: JOSM,  - see Export menu *




From the OSM OPL history  - very easy to grep the first contributor

# convert the osm history file to OPL ( *osmium cat w11323607.osh  -f opl*  )
# sample OSM History OPL file:
#  w100646626 v1 dV c7343540 t2011-02-20T15:08:57Z i37137
uDerick%0020Rethans Tbridge=yes,highway=footway
Nn309461645,n1163494643
#  w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
Tbridge=swing,highway=footway Nn309461645,n1163494643
#  w100646626 v3 dV c18538313 t2013-10-25T16:16:57Z i24119 uMauls
Tbridge=swing,highway=footway Nn309461645,n2508499967
#  w100646626 v4 dV c25024407 t2014-08-26T10:51:45Z i66391 ugeozeisig
Tbridge=movable,bridge:movable=swing,highway=footway
Nn309461645,n2508499967
#  w100646626 v5 dV c25050883 t2014-08-27T12:42:02Z i66391 ugeozeisig
Tbridge=swing,highway=footway Nn309461645,n2508499967
#
# filter the results by the first contributor who added bridge=swing to the way
# ( *egrep -m 1 '( T|,)bridge=swing'* )
#result: v2
#  w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
Tbridge=swing,highway=footway Nn309461645,n1163494643
#


The OPL format - from the OSMIUM manual:

v - Version

d - Deleted flag ('V' - visible or 'D' - deleted)

c - Changeset ID

t - Timestamp (ISO Format)

i - User ID

u - Username

T - Tags

x - Longitude (nodes only)

y - Latitude (nodes only)

N - Nodes (ways only)

M - Members (relations only)


you can find other interesting examples in the OSMIUM manual

Find all users who have created post boxes:

egrep ' v1 ' data.osm.opl | egrep 'amenity=post_box' | cut -d' ' -f7 |
cut -c2- | sort -u


OSMIUM tool - and more examples :

http://osmcode.org/libosmium/manual/libosmium-manual.html#output-formats
https://www.sotm-eu.org/en/slots/36
https://www.sotm-eu.org/slides/44.pdf



Imre



2014-08-28 12:39 GMT+02:00 Richard Z. ricoz@gmail.com:

 Hi,

 trying to clean up bridge=swing as far as possible. There was at least
 user in the past who used the combination systematically wrong, so I want
 to split the result by user who introduced the bridge=swing.

 To make things complicated - a few days ago one contributor did a well
 meant effort to convert all
   bridge=swing - bridge=movable+bridge:movable=swing
 and reverted that edit because there were too many errors in it. Hence
 doing a naive search for user doesn't work.

 So I want to :
  * find all bridge=swing
  * split results by the first contributor who added bridge=swing
to the way
  * get the results into JOSM for examination and editing

 Tia for any hints,
 Richard

 ___
 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] need advice for clever query or script

[Imre Samu]

 if I would want to compile osmium myself the README says
 that no files need to be build and doesn't say where osmium comes from?

I have used the code and instructions from this 2 repo
https://github.com/osmcode/libosmium  (  osmium library )
https://github.com/osmcode/osmium-tool ( osmium command line tool )

if you have a some problems with the installation,
   then I can create a Docker Container ( www.docker.com ) for you.

Imre



2014-08-29 15:55 GMT+02:00 Richard Z. ricoz@gmail.com:

 On Fri, Aug 29, 2014 at 02:22:10PM +0200, Imre Samu wrote:

 Hi Imre,


 thousands thanks - everything seems to work perfectly as described.

 one question - if I would want to compile osmium myself the README says
 that no files need to be build and doesn't say where osmium comes from?


 Richard

 
   clever query or script
 
  maybe you can use OSM OPL format this ad-hoc query,
  and process the data  with sed, awk, grep .
 
  my draft ubuntu script - with comments.
 
 
 https://gist.github.com/ImreSamu/be49fd1ce511975325d2#file-bridge_swing-sh
 
  result (  Overpass-Wizard Query - but you can export the data to JOSM   )
 
 
 https://gist.github.com/ImreSamu/a2dd0a8c25f0fea5284c#file-bridge_swing_overpass_wizard-md
 
 
  the example result - Overpass-Wizard Query :
 
  type:way and ( id:28134411 or id:29295367 or id:30178341 or id:30178382
 or
  id:33132931 or id:33132936 or id:33132949 ) global
 
 
  ( http://wiki.openstreetmap.org/wiki/Overpass_turbo/Wizard - see
  Meta-Data Filters )
 
  *How to check the query *
 
  ** go  http://overpass-turbo.eu/ http://overpass-turbo.eu/ *
  ** select Wizard*
  * * copy /paste the generated query :   type:way and ( id:27001207 or
  id:72584563 )  global*
  * * Build and run query - and check the result.*
  * * if you got timeout error, then check the generated script timeout (
  osm-script output=json timeout=25 )  and set to 200 - and rerun
 *
  ** you can load data into an OSM editor: JOSM,  - see Export menu *
 
 
 
 
  From the OSM OPL history  - very easy to grep the first contributor
 
  # convert the osm history file to OPL ( *osmium cat w11323607.osh  -f
 opl*  )
  # sample OSM History OPL file:
  #  w100646626 v1 dV c7343540 t2011-02-20T15:08:57Z i37137
  uDerick%0020Rethans Tbridge=yes,highway=footway
  Nn309461645,n1163494643
  #  w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
  Tbridge=swing,highway=footway Nn309461645,n1163494643
  #  w100646626 v3 dV c18538313 t2013-10-25T16:16:57Z i24119 uMauls
  Tbridge=swing,highway=footway Nn309461645,n2508499967
  #  w100646626 v4 dV c25024407 t2014-08-26T10:51:45Z i66391 ugeozeisig
  Tbridge=movable,bridge:movable=swing,highway=footway
  Nn309461645,n2508499967
  #  w100646626 v5 dV c25050883 t2014-08-27T12:42:02Z i66391 ugeozeisig
  Tbridge=swing,highway=footway Nn309461645,n2508499967
  #
  # filter the results by the first contributor who added bridge=swing to
 the way
  # ( *egrep -m 1 '( T|,)bridge=swing'* )
  #result: v2
  #  w100646626 v2 dV c12447614 t2012-07-23T09:52:38Z i404175 urickogden
  Tbridge=swing,highway=footway Nn309461645,n1163494643
  #
 
 
  The OPL format - from the OSMIUM manual:
 
  v - Version
 
  d - Deleted flag ('V' - visible or 'D' - deleted)
 
  c - Changeset ID
 
  t - Timestamp (ISO Format)
 
  i - User ID
 
  u - Username
 
  T - Tags
 
  x - Longitude (nodes only)
 
  y - Latitude (nodes only)
 
  N - Nodes (ways only)
 
  M - Members (relations only)
 
 
  you can find other interesting examples in the OSMIUM manual
 
  Find all users who have created post boxes:
 
  egrep ' v1 ' data.osm.opl | egrep 'amenity=post_box' | cut -d' ' -f7 |
  cut -c2- | sort -u
 
 
  OSMIUM tool - and more examples :
 
  http://osmcode.org/libosmium/manual/libosmium-manual.html#output-formats
  https://www.sotm-eu.org/en/slots/36
  https://www.sotm-eu.org/slides/44.pdf
 
 
 
  Imre
 
 
 
  2014-08-28 12:39 GMT+02:00 Richard Z. ricoz@gmail.com:
 
   Hi,
  
   trying to clean up bridge=swing as far as possible. There was at least
   user in the past who used the combination systematically wrong, so I
 want
   to split the result by user who introduced the bridge=swing.
  
   To make things complicated - a few days ago one contributor did a well
   meant effort to convert all
 bridge=swing - bridge=movable+bridge:movable=swing
   and reverted that edit because there were too many errors in it. Hence
   doing a naive search for user doesn't work.
  
   So I want to :
* find all bridge=swing
* split results by the first contributor who added bridge=swing
  to the way
* get the results into JOSM for examination and editing
  
   Tia for any hints,
   Richard
  
   ___
   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] need advice for clever query or script

[Imre Samu]

I have cleaned my Dockerfile - maybe you can use.
( if you replace RUN to   sudo  - you can install line - by line  )
https://gist.github.com/ImreSamu/5447252a4e750fd8c61e#file-dockerfile_for_install_osmium_tool

good luck :)
  Imre



2014-08-29 16:37 GMT+02:00 Richard Z. ricoz@gmail.com:

 On Fri, Aug 29, 2014 at 04:12:08PM +0200, Imre Samu wrote:
   if I would want to compile osmium myself the README says
   that no files need to be build and doesn't say where osmium comes from?
 
  I have used the code and instructions from this 2 repo
  https://github.com/osmcode/libosmium  (  osmium library )
  https://github.com/osmcode/osmium-tool ( osmium command line tool )

 ok, the https://github.com/osmcode/osmium-tool was the missing link.


  if you have a some problems with the installation,
 then I can create a Docker Container ( www.docker.com ) for you.

 hopefully not necessary.. I do not need it quickly and if I will do it
 will try to create all the RPM specfiles.


 Richard

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

Re: [OSM-talk] need advice for clever query or script

[Imre Samu]

 I have got one problem, some of the queries with most bridges do
 not load into JOSM. Josm says contacting the server and thats all.

strange ... :(
maybe timeout when generate JOSM data?

but you can optimize the query

some tips:

*#1.  if you know wich country  -  replace the global  keyword in the
query to the precise territory filter ..*
( see Location Filters  in
http://wiki.openstreetmap.org/wiki/Overpass_turbo/Wizard )

global   -in USA
global   -in Vienna
global-   in Netherlands


*#2. You can split the   big query-s - to smaller ones ..*


from this big query

type:way and ( id:105807680 or id:128093288 or id:135527140 or id:140757611
or id:158593665 or id:158608739 or id:158608747

or id:162817769 or id:162988896 or id:163435617 or id:163451937 or
id:163640424 or id:186555649 or id:186667441 or id:190721707

 or id:193652513 or id:196184968 or id:199818438 or id:242264939 or
id:245514123 or id:268020828 or id:300530708 or id:42712814

or id:50483896 or id:51513287 or id:51831532 or id:52209220 or id:59430361
or id:88300946 or id:88863770 or id:99211716 ) global


you can manually create 4 sub - query  and you have to run 4 times.

-1)  type:way and ( id:105807680 or id:128093288 or id:135527140 or
id:140757611 or id:158593665 or id:158608739 or id:158608747 )   global

-2)  type:way and ( id:162817769 or id:162988896 or id:163435617 or
id:163451937 or id:163640424 or id:186555649 or id:186667441 or id:190721707
 ) global

-3)  type:way and (  id:193652513 or id:196184968 or id:199818438 or
id:242264939 or id:245514123 or id:268020828 or id:300530708 or id:42712814 )
global

-4)  type:way and ( id:50483896 or id:51513287 or id:51831532 or
id:52209220 or id:59430361 or id:88300946 or id:88863770 or id:99211716 )
global



*Other solution -Filter in JOSM*

*  JOSM  File / Open location  :
http://www.overpass-api.de/api/xapi_meta?way[bridge=swing]
*   and after open the Filter menu (   Windows→Filter from the menu, or
Alt+Shift+F from the keyboard)

https://wiki.openstreetmap.org/wiki/JOSM/Search_function

https://www.mapbox.com/blog/2012-08-15-using-filters-josm/

* and copy the query  ( without the global  keyword ( ..maybe... )   )

but I am not perfect in JOSM ...   so if you find th correct JOSM filtering
please share with me ...  :)



Imre




2014-08-29 23:24 GMT+02:00 Richard Z. ricoz@gmail.com:

 On Fri, Aug 29, 2014 at 02:22:10PM +0200, Imre Samu wrote:

 Hi Imre,

 I have got one problem, some of the queries with most bridges do
 not load into JOSM. Josm says contacting the server and thats all.

 When I share the query the shorturl looks like the one bellow so
 it seems to be somehow an issue at http://overpass-turbo.eu/ ?

 
 http://overpass-turbo.eu/?q=PCEtLQpUaGlzIGhhxIhiZWVuIGfEj2VyYXRlZCBieSB0aGUgb3bElHDEi3MtdHVyYm8gd2l6YXJkLsSExJ_EoXJpZ2luYWwgc2XEsmNoxK7EizoKw6LCgMKcdHlwZTp3YcScYW7EmSggaWQ6MTA4MTYzMzI4xLjFmcWbxZ3Fn8WhMzQzxabFmsWcxZ4xNzc2OTbFr8WoMTI0NzHFvzTFucWcxaQ1NTLFtsaBb3LFp8WcNcW3NTDFoMaCMTnFssW_M8WlxorGjMaUODkxOMaYxpnGi8WwMsWgxb_GkDc5xoLGpcadMMW-MDLGqzPFnTkzxrXGssW_ODI3xa7GmsakxaIyNca8xbTGssaYMMWjMMW4xr7FmzLFrDXFvTM3NcayNDjFnjY3xqLGjMW8MzU2Mca2N8arNDTFs8WixonGo8eMNMaGODjHkseKx6k6xbzGjsWhxrXHoseLx7LFvceeNsa6x6M5xoYwx7_HqMebxpA4xbbFs8arNcWixo7Hlse3x7HHgTY0yJHGjsaxx7jIkMiSyJLFnciJx6_FvDfIlciPNca6MMaux6TGqzbHicawxoUwyKbIkjXGnzTIq8iWNseYxpTHpMaqyJbInse2x5jGq8eSxaAzNsifx5vHmcWgyIrJgcakODQ5Ociex5rJhznGu8erxZ_Gq8adx6XHn8eNyZM5yZXFu8iDyY7JmseByZjJnsewx5vGtceex6TFtsarx7_HgsW1xqnJqMeexoTJj8aCxrPHmceHOMeTx7jHiDfIo8iwybHGh8iBxoTJvMetxZ7Iv8mxx5EyxbzJn8m3x5HGtcW9yLfHscWsxbbJi8W-ybHIrsm9ybnKk8W7yKfInsqTx4_Grcm2yo7GhcqLx6XJscW2x53GucqjyaTFu8mGxZvIv8qoxrbKp8edyobKjcaMyqzHncWjyqo6yrTIisizyq_IismKyrzKusq8x5nGvcexx6XIhsecyI7GjMerx57Hrsm1xoLJkcmlyobLjsmWx4fGnsuOybnIhsilx7jGkMijxbfKt8iuxpXHgcW3xoLLn8awyYDKssWwy5_GhceGy6PKoDDHlcmNxZvGjsijxpjHv8aCx5_Ktse8y7A6yLPIvsmXx7jGoMefy5fGgsyAxbPGksu_yL_HrsW0yLHHscyAzInLtcu_yIrGnceuzIvGjMW3x63HvMaRICnEkWxvYsS-IMWKwp0KxII-Cjxvc20tc2PEuXB0xKF1dHDMsz0ieG1sIsSdaW1lb8y2IseBIj7EgMSCIGZpeMSYxJrFlMyzxK1yZcSlacaLzKUKICDNhy3EkcSWxJ_Gi82Sc3VsdMSIzZfNmTx1bmlvbsymzZnNqMSBzZxxdcSUxJzEpXLMsWbGijrMocWLxbDFqci-xaM4zKIgzafNsDzNtM22xJ3FjmXMt8WSec2FzZjNsM2oxZotzopyxJzFjcWPzo_Fk8y8zZJmzLfOgcWrxaQiL82vzogvzph5zqjNsc2IzqsgzbjNus28zb7CnM6AxbLFq8WtzoXOh82ozrDOm86OIs6QzpLOlM6VZM6XzbXOmc6MzpzPgc6eIM6gzqLOuMenM86mzq3Nms6qz4jOrM6Tzq7Ns8-YzrHEss6zcs29xYrOtsWoxbLFtMW2Ns67Lc-VzonPnc6_zp3Okc-Vz4XPh86Lz6_PjM6Rz45lzqEizoHPp8W3z5TPms-WzqvPrM2yIM6wzrLNic60z6POgMmbxb7GgM-qz6zOvs6Nz7DPg8-EPM6W0JLPi8-Cz7nPu8W_yJ3FvzE00IDOlDzPl8220ITOr8-d0IjNu8-hzrXOgMaExobGiNCQ0IHPrc-10JPPt9CV0KTQmM-u0LfQm8-Pz7zQsMaHyZnQo86p0IPQtNCF0IfPn9CJ0K3Qi8Wox7TGkMWg0LPQpNCZz4DPgs-yzZrQu9C20JrPjdC_MdGPxpE20YTNqNCmzpnQqM-czovQq9CKzb_FqMaVxZ_Gl86EwoDCnc6Gz6vQtNGU0JTRl9CXz4bRttC40JzOotGt0KDGmNGi0ILPmNGm0IbQqtGK0KzPotGrxZw5xp3Gn8ah0ZLOiNG70ZbQgc-z0pPRnM-60b7Sjsagx63SgtCl0YbQpNGI0ofNudGL0orPpMeyxqbRnsauOdKRzr3QvNGbz7HSldGY0brSr9GV0pjPu8alx5_Sqsap0p7RpM-Z0qHQqdGo0ojRqtKnxqzGlcavMtKtzZrSl9Kxz4TSs8-0z4nPttC