[OSM-talk] Android Network Location Providers?

[Paul Johnson]

As I've experienced unusually poor performance with Google's NLP in
Android, I was wondering if anybody knew of a dropin replacement I can
install that cuts Google's NLP while still allowing NLP through some kind
of open means, even if self-generated on the device?

MicroG Unified NLP doesn't work in this case as I have a number of apps
that depend on Google Play Services, which MicroG pretty much makes
unusable.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to locate errors

[Hendrik Hoeth]

Hello again,

I've imported Europe from geofabrik.de (2015-02-08), made sure I didn't
use the wrong table, and Lac Leman is still missing. So how would I
proceed? I have no idea how to debug this.

Cheers,

Hendrik

-- 
I want to know God's thoughts, the rest are details.
 -- Albert Einstein

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

Re: [OSM-talk] Android Network Location Providers?

[Richard Z.]

On Tue, Feb 10, 2015 at 02:36:13AM -0600, Paul Johnson wrote:
> As I've experienced unusually poor performance with Google's NLP in
> Android, I was wondering if anybody knew of a dropin replacement I can
> install that cuts Google's NLP while still allowing NLP through some kind
> of open means, even if self-generated on the device?

f-droid.org has something, and more pointers in forums. I have not
tested any of these.


Richard

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

Re: [OSM-talk] How to locate errors

[Jo Walsh]

On Tue, Feb 10, 2015, at 06:14 AM, Hendrik Hoeth wrote:
> Hello again,
> 
> I've imported Europe from geofabrik.de (2015-02-08), made sure I didn't
> use the wrong table, and Lac Leman is still missing. So how would I
> proceed? I have no idea how to debug this.

The relation for Lac Leman / Lake Geneva looks fine in the renderer:
http://www.openstreetmap.org/relation/332617

So i suggest it's a problem with your query, not with the data itself?
I can have a look via osmpgsql and report back, may not help much.


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

Re: [OSM-talk] Android Network Location Providers?

[Joseph Reeves]

Hi Paul,

Is Mozilla Location Service useful to you?
https://location.services.mozilla.com/

Cheers, Joseph



On 10 February 2015 at 08:36, Paul Johnson  wrote:

> As I've experienced unusually poor performance with Google's NLP in
> Android, I was wondering if anybody knew of a dropin replacement I can
> install that cuts Google's NLP while still allowing NLP through some kind
> of open means, even if self-generated on the device?
>
> MicroG Unified NLP doesn't work in this case as I have a number of apps
> that depend on Google Play Services, which MicroG pretty much makes
> unusable.
>
> ___
> 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 locate errors

[Hendrik Hoeth]

Hi,

Thus spake Jo Walsh (metaz...@fastmail.net):

> The relation for Lac Leman / Lake Geneva looks fine in the renderer:
> http://www.openstreetmap.org/relation/332617
> 
> So i suggest it's a problem with your query, not with the data itself?

Might be. What confuses me is that all other water bodies I've looked at
seem fine, and the same query had worked in the past.

> I can have a look via osmpgsql and report back, may not help much.

That would be great! Thanks!

Hendrik

-- 
I want to know God's thoughts, the rest are details.
 -- Albert Einstein

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

[OSM-talk] Drones piece in Guardian

[Steve Chilton]

Does anyone have email contact for Ivan Gayton please?
Featured in article in Guardian Saturday on drones:
http://www.theguardian.com/technology/2015/feb/07/battle-of-drones-amateurs-taking-on-tech-giants
I would like to speak to him about possibly giving a talk about his 
OpenStreetMap work.

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/

[cid:image001.jpg@01D04523.D6B6CAE0]




---


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

Re: [OSM-talk] How to locate errors

[Jo Walsh]

On Mon, Feb 9, 2015, at 10:24 AM, Hendrik Hoeth wrote:
> - Import planet-150202 into psql-database using imposm. Settings are at
>   the bottom of this mail.
> 
> - The Lake Geneva (Lac Leman, Switzerland) is missing. There is no
>   polygon data for the lake in my database. Anything else I've looked at
>   seems to be fine.
> 
> How would I find out what to fix?

Reading back, your problem is probably with imposm being picky; Lac
Leman is a multipolygon relation, and you're only importing regular
polygons in your settings file. Vanilla imposm may also be skipping big
relations? see
http://imposm.org/docs/imposm/latest/tutorial.html#multipolygon-relation-building
 

There is a helpful imposm forum on which i've had advice before and
you're probably much better off asking there.
https://groups.google.com/forum/#!forum/imposm Today i'm experimenting
with osm2psql and having a better time with that than imposm, involves
less upfront thinking. 

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

Re: [OSM-talk] Drones piece in Guardian

[Tom Hughes]

On 10/02/15 11:22, Steve Chilton wrote:


Does anyone have email contact for Ivan Gayton please?

Featured in article in Guardian Saturday on drones:

http://www.theguardian.com/technology/2015/feb/07/battle-of-drones-amateurs-taking-on-tech-giants

I would like to speak to him about possibly giving a talk about his
OpenStreetMap work.


https://twitter.com/ivangayton looks like him?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-talk] Android Network Location Providers?

[Paul Johnson]

I'd be curious if you have specific links.
On Feb 10, 2015 4:47 AM, "Richard Z."  wrote:

> On Tue, Feb 10, 2015 at 02:36:13AM -0600, Paul Johnson wrote:
> > As I've experienced unusually poor performance with Google's NLP in
> > Android, I was wondering if anybody knew of a dropin replacement I can
> > install that cuts Google's NLP while still allowing NLP through some kind
> > of open means, even if self-generated on the device?
>
> f-droid.org has something, and more pointers in forums. I have not
> tested any of these.
>
>
> Richard
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Android Network Location Providers?

[Paul Johnson]

Not quite, but close.  MicroG would be perfect if it didn't totally disable
other Google Play services.
On Feb 10, 2015 5:14 AM, "Joseph Reeves"  wrote:

> Hi Paul,
>
> Is Mozilla Location Service useful to you?
> https://location.services.mozilla.com/
>
> Cheers, Joseph
>
>
>
> On 10 February 2015 at 08:36, Paul Johnson  wrote:
>
>> As I've experienced unusually poor performance with Google's NLP in
>> Android, I was wondering if anybody knew of a dropin replacement I can
>> install that cuts Google's NLP while still allowing NLP through some kind
>> of open means, even if self-generated on the device?
>>
>> MicroG Unified NLP doesn't work in this case as I have a number of apps
>> that depend on Google Play Services, which MicroG pretty much makes
>> unusable.
>>
>> ___
>> 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] "How We Map"

[Jo Walsh]

dear all,

I wish to float this draft page for discussion and possibly future
approval!

http://wiki.openstreetmap.org/wiki/How_We_Map

The page is a summary of a draft Mappers' Code written by Frederik some
time ago after extensive discussion with the rest of the DWG. When I
signed up to the DWG I tried to condense that draft into a
single-screen, single-page, easily digestible version appropriate to
show to new mappers and to put on the registration pages. My ideal for
the doc is that it expresses the core principles of contributing to OSM
without besetting anyone with rules, and that it's as short as possible
without missing out anything important to know. I encourage people to
post scathing critiques on the Talk: page in addition to here on the
list. 

http://wiki.openstreetmap.org/wiki/Talk:How_We_Map

For the benefit of the really lazy or bandwidth-deprived, I include the
full text of "How We Map" as it stands now, below the fold.

be well all,



OpenStreetMap is a social activity; it is a teamwork effort by hundreds
of thousands of people around the globe.

OpenStreetmap has a tradition of making as few rules as possible.

Contributions to OpenStreetmap should be:

Truthful - means that you cannot contribute something you have
invented.
Legal - means that you don't copy copyrighted data without
permission.
Verifiable - means that others can go there and see for themselves
if your data is correct.
Relevant - means that you have to use tags that make clear to others
how to re-use the data

When in doubt, also consider the "on the ground rule": map the world as
it can be observed by someone physically there.

OpenStreetMap has very few rules on tagging. There are tagging standards
but they evolve instead of being pushed through.

OpenStreetMap values local knowledge highly, but mappers should welcome
edits from outsiders.

OpenStreetMap values community cohesion over data perfection.

You do not have to ask permission before modifying existing data. If you
believe that you can improve something, then do it.

In talking to other mappers, always assume good intentions.

If you have a conflict with another mapper that you cannot solve amongst
yourselves, involve other project members - via the local community
meetup, the regional mailing list or areas of the forum, or by messaging
them directly.

Occasionally you will be contacted by other mappers about edits you have
made. Please do not ignore them; if the other mapper has taken the time
to look at your edit and ask you a question, they deserve an answer.

Do not delete data unless you know (or have very strong reason to
believe) that it is incorrect.

Do not engage in large-scale "cleanups" without securing the agreement
of the relevant community, or talking to the people whose work you aim
to "clean".

You may believe your third-party dataset should be added to OSM. Do not
bulk import data from other sources without first discussing and
securing agreement on the imports list. 

-- 
  Jo Walsh
  metaz...@fastmail.net

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

Re: [OSM-talk] How to locate errors

[Hendrik Hoeth]

Hi,

Thus spake Jo Walsh (metaz...@fastmail.net):

> > How would I find out what to fix?
>
> Reading back, your problem is probably with imposm being picky; Lac
> Leman is a multipolygon relation, and you're only importing regular
> polygons in your settings file.

No, multipolygons are imported in the same way as polygons. No need to
differentiate in the settings file. For example Vänern in Sweden works
just fine (see attached GRASS screenshot), and it's not exactly a small
multipolygon either: http://www.openstreetmap.org/relation/1239458

> Vanilla imposm may also be skipping big relations?

No. They are reported if they take more than 60 seconds to import, but
they are not skipped.

I've imported and rendered the whole earth last year using that very
same imposm installation and settings file, without any trouble. That's
what confuses me ...

> Today i'm experimenting with osm2psql and having a better time with
> that than imposm, involves less upfront thinking.

Let me know if you find out anything! Thanks so much!

Cheers,

Hendrik

-- 
I want to know God's thoughts, the rest are details.
 -- Albert Einstein
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Android Network Location Providers?

[Richard Z.]

On Tue, Feb 10, 2015 at 06:00:29AM -0600, Paul Johnson wrote:
> I'd be curious if you have specific links.

one that I was looking at is this:

https://f-droid.org/repository/browse/?fdfilter=location&fdid=org.fitchfamily.android.gsmlocation&fdpage=2


Richard

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

Re: [OSM-talk] How to locate errors

[Daniel Koć]

W dniu 2015-02-10 o 11:58, Jo Walsh pisze:

So i suggest it's a problem with your query, not with the data itself? 
I can have a look via osmpgsql and report back, may not help much. 


May the reason be tagging it as natural=water+water=lake?

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

Re: [OSM-talk] How to locate errors

[Hendrik Hoeth]

Hi Daniel,

Thus spake Daniel Ko?? (daniel@ko??.pl):

> >So i suggest it's a problem with your query, not with the data
> >itself? I can have a look via osmpgsql and report back, may not
> >help much.
> 
> May the reason be tagging it as natural=water+water=lake?

So are many other lakes, Vänern being one working example. That
shouldn't be a problem. If it's natural=water, I should take it.

Cheers,

   Hendrik

-- 
I want to know God's thoughts, the rest are details.
 -- Albert Einstein

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

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

[colliar]

Hey

Maybe, it is me only to slow in reverting and solving these mistakes or
even the bugs I incounter in JOSM while working but I am definitely feed
up with talking about the same things over and over again and I am
probably not even polite enough to do the job of communicating.

So what to do ? Silently reverting is not an option. Always getting DWG
involved neither.

I am fed up with:
* iD making it way to easy to delete objects but not offering an option
to undelete them (is there any history information at all ?)
* simply combining ways and merge nodes without any validation or
warning about conflicts in tags or problems with relations
* not telling the user about the importance of all tags, even unknown to
the software and allowing user to communicate with user of the last
change of the object

Any plans of supporting lanes-tagging-system ? Otherwise there will be
even more complains in the future.

Is there anyone taking care of mistake made by iD users and documenting
the most common ones to either better explain how to avoid them and/or
fix the software ?

As iD is supposed to be the newbie editor all mistakes will rather turn
them down than encourage them.

So far, I try to keep calm and rather save my changes and upload them
later after solving conflicts instead of starting an edit war by
reverting or uploading older versions but I spend more time with
communication and investigating problems than actually mapping and
resolving notes and I still have quite some gpx tracks and photos from
over a year ago to map.

How about simply denying some changes with iD like combining ways ?

Cheers colliar


0xE8F56581.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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

[SomeoneElse]

On 10/02/2015 23:38, colliar wrote:

... I am fed up with ...


... at this point it's probably worth mentioning that we've been here 
before:


https://lists.openstreetmap.org/pipermail/talk/2013-August/thread.html#67854

Unfortunately, experience suggests that there's relatively little that a 
discussion on on the "talk" mailing list is going to be able to do 
here.  There are essentially two sides to the argument - at one extreme 
new mappers "should never be able to break data" (and if they can't edit 
at all because they can't understand what they need to do, tough) and at 
the other new mappers "must have everything complicated hidden from 
them" (and if some complicated OSM structure breaks, tough).  Obviously 
you're not at one extreme and the iD developers aren't at the other, but 
there _is_ a difference of opinion here that it's not easy to 
reconcile.  If you want new mappers, you have to actually allow them to map.


If you've got specific examples of things that new users get wrong 
consistently (and even better if you can understand what they've done 
wrong and why) then I suspect that it would really help would be to 
raise an issue on Github about it, or add to an existing one if one 
already exists.



* iD making it way to easy to delete objects but not offering an option
to undelete them (is there any history information at all ?)


Whilst I'm in no way a fan of the iD user interface, even I had no 
problems finding the "undo" button.  I don't think that new mappers tend 
not to find it either, since an answer to the common question "what do I 
do if I get a conflict" is "undo back past the problem", and new mappers 
haven't said (on the help site or on IRC) "how do I undo"?



* simply combining ways and merge nodes without any validation or
warning about conflicts in tags or problems with relations


What might help here is to get details from the new mapper concerned of 
how they felt that they needed to merge nodes or ways.  The "merge" 
operation is fairly visually obvious when it happens; what's not so 
obvious is that the resulting merged node with semicolon-separated tag 
values isn't particularly useful in OSM.


There are a couple of "merge" Github issues; it may be that they already 
describe the problem that you are referring to here.



* not telling the user about the importance of all tags, even unknown to
the software and allowing user to communicate with user of the last
change of the object


I suspect that this comes down to the "two sides to the argument" 
mentioned above - the idea is that new mappers shouldn't have to worry 
about "all tags" (or indeed, where possible, tags at all).




Any plans of supporting lanes-tagging-system ? Otherwise there will be
even more complains in the future.


This sounds like https://github.com/openstreetmap/iD/issues/387 to me.  
That's probably the best place to explain what you'd want the end result 
of a "new mapper knowing about turn lanes" would be.




Is there anyone taking care of mistake made by iD users and documenting
the most common ones to either better explain how to avoid them and/or
fix the software ?


Back in 2013 I did have a look, and came up with this:

https://lists.openstreetmap.org/pipermail/talk/2013-August/068018.html

Since then the "Thing X changed to thing Y" problem has been much 
diminished by the fix for iD issue 542.  "POI added without a main tag" 
is still pretty common, and "unexpected deletions" are rarer than the 
were (perhaps also because of the iD 542 fix).


The initial "who made what sort of error" analysis was in 
https://lists.openstreetmap.org/pipermail/talk/2013-August/067936.html , 
and note that in there iD new users made statistically fewer serious 
errors than P2 ones (or, on a very low sample size, JOSM users).  I 
don't have the numbers, but based on a gut feel since 2013 I'd say that 
currently the editor for which the highest proportion of new users are 
going to cause _widespread_ problems is probably JOSM.



... So far, I try to keep calm and rather save my changes and upload them
later after solving conflicts instead of starting an edit war by
reverting or uploading older versions but I spend more time with
communication and investigating problems than actually mapping and
resolving notes and I still have quite some gpx tracks and photos from
over a year ago to map.



Supportive communication with new users is really important, so thanks 
for taking the time to do this.


I don't believe that OSM has an "iD users" problem; it has a "new 
mappers" one -  or more accurately, a "data far more complicated than it 
needs to be" problem which means even experienced mappers can have 
problems.  For example, have a look at this help question and the ones 
that it links to:


https://help.openstreetmap.org/questions/40792/editing-large-multipolygons-in-josm

Those were asked by an experienced OSM mapper who usually edits in JOSM 
- how's someone without an in-depth knowledge of h

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

[Jo Walsh]

> What might help here is to get details from the new mapper concerned of 
> how they felt that they needed to merge nodes or ways.  

I use changeset discussions a fair bit, partly because they end up right
in the new mapper's inbox, and that provides a link to an outside view
of the new mapper's changes. I always wish it was more obvious how to
explore the history of the related nodes and ways and see the editors of
related changesets from the changeset landing page, but at least it's
all there in the links, at least in theory.

Ideally a calm discussion leads to someone engaging a bit more and
fixing the problem themselves, though more often it's a polite prelude
to a future reversion :/

> > * not telling the user about the importance of all tags, even unknown to
> > the software and allowing user to communicate with user of the last
> > change of the object
> > ... So far, I try to keep calm and rather save my changes and upload them
> > later after solving conflicts instead of starting an edit war by
> > reverting or uploading older versions but I spend more time with
> > communication and investigating problems than actually mapping 

On the one hand I'm sorry to hear that communicating and fixing is a
distraction from mapping for you, on the other you're starting to sound
like a candidate member of the DWG ;) Maybe consider it, validating an
activity you're pursuing anyway...


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