Re: [OSM-talk] Portal for users/casual mappers (Re: Tagging FOR the renderer)

[Bryce Nesbitt]

On Mon, May 18, 2015 at 9:14 AM, Simon Poole  wrote:
>
> You must have misunderstood something there, the top 50'000 (roughly 10%
> of all) or so mappers have contributed essentially all (roughly 95%)
> data to OSM. The long tail is not unimportant, but from a pure volume
> point of view OSM is very dependent on its core contributors. Not that
> this is a surprise or different than any other similar enterprise.
>

Keep in mind the type of contribution is different.

This year I edited 250,000 trees with a bad tag.  That's a huge number of
nodes, but not a significant contribution of knowledge.
The "long tail" editors on the other hand may be supplying data in unique
ways requiring local knowledge.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] a, b and c.tile.openstreetmap.org refer to the same server?

[Stefan Baebler]

18. maj 2015 10.30 pop. je oseba "Andrew Guertin" 
napisala:
> Whether the new limits are sufficiently high for OSM I haven't
investigated enough to answer.

Browser limits, network speeds and screen resolutions all increased in the
recent years, but tile size stayed at 256*256.

To put this in perspective, currently trending 1920*1080 needs 40-54 tiles
for a full screen map, whereas 1024*768 (most popular in 2009) only needed
12-20.
Source: http:// www.screenresolution.org/
 + quick calculation.

Average tile complexity also increased somewhat, increasing their average
size in kB.

Using a,b,c hostname aliases only increases initial DNS resolution time.

This hack IMO still serves as a relatively cheap performance boost... until
HTTP 2 is widely used.

best regards,
Stefan
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging FOR the renderer

[François Lacombe]

Such topics are curently discussed during the voting of a power tagging
proposal on the wiki.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement
Have a look to the voting section.

As I understand, renders is A (out of plenty) way to look at the data.
It sounds very restrictive to make the data look like just a few people
want to see it. What about ones who just want to produce data without
looking at it from a narrow window ?

The main argument opposed is often "oh wait, this would cause a rendering
issue". Thus, why the render can't adapt if the information is available in
the data ?

I totally agree with people who separate data from renders (structure from
styles). It can be very frustrating to often prevent a good structure from
existing because styles won't match.

OSM should look at this problem deeply and make strong choices, before
letting other sorts of contributors to leave the boat.


All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2015-05-18 12:19 GMT+02:00 moltonel 3x Combo :

> On 18/05/2015, Daniel Koć  wrote:
> > I think the mission will be accomplished once we have it integrated with
> > OSM website somehow, just like we did with routing: there were already a
> > few routing services using our data, so we may not care, but for average
> > user they were just not here. And so is uMap.
>
> Routing is different in that it is immediately useful to
> *contributors*, who can now check that the OSM data is correct for
> routing, just like the slippymap is useful to check that the data
> looks good. uMap not so much : as a contributor, I'd rather use josm,
> taginfo, overpass, or even data dumps.
>
> As nice as it'd be, http://osm.org/ is not trying to be
> http://maps.google.com/. It's not trying to be the One True Map Portal
> that caters to every needs.
>
> Some reasons off the top of my head, some strong and some weak :
>  * The needs of contributors and users can easily conflict, and
> priority is/should be given to the contributors.
>  * Even without conflicts, the size of the contributor-focused todo
> list means that enduser-focused features get constantly pushed back.
> Help welcome.
>  * Becoming the internet's one-stop map website would require huge
> server ressources. Getting the kind of money required to run them
> would require huge changes to the way OSM is run, which'd be dangerous
> for OSM's freedom.
>  * Similarly for manpower requirements; volunteers wouldn't be enough
> anymore.
>  * A healthy ecosystem of commercial users is important for OSM. And
> they should be able to do a better job of serving the end-user, so
> it's probably a bad idea to compete with their use-case.
>
> ___
> 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] a, b and c.tile.openstreetmap.org refer to the same server?

[Andrew Guertin]

On 05/17/2015 11:09 AM, Jochen Topf wrote:

(Modern browsers probably don't have this limitation any more, sombody should
probably check whether we need the a/b/c stuff any more.)


I gave this a quick check, Firefox's was last changed in 2008:
http://hg.mozilla.org/mozilla-central/rev/d57879bc8021
https://bugzilla.mozilla.org/show_bug.cgi?id=423377

A quick read through of the bug showed that other browsers were 
increasing their limits at around the same time. That means that the 
changes should have propagated to nearly all users by now.


Whether the new limits are sufficiently high for OSM I haven't 
investigated enough to answer.


--Andrew

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

Re: [OSM-talk] Portal for users/casual mappers (Re: Tagging FOR the renderer)

[Simon Poole]

Am 18.05.2015 um 15:18 schrieb Daniel Koć:

...
> 
> The most of the work in OSM is done not by the few hundreds of advanced
> users, but by much more casual mappers.
...

You must have misunderstood something there, the top 50'000 (roughly 10%
of all) or so mappers have contributed essentially all (roughly 95%)
data to OSM. The long tail is not unimportant, but from a pure volume
point of view OSM is very dependent on its core contributors. Not that
this is a surprise or different than any other similar enterprise.

Simon



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD name suggestion index - asking non-English-speaking mappers to review

[John F. Eldredge]

Is there a company in Australia named Petrol, or is it simply the term for the 
fuel? As I understand it, the question is whether Petrol is valid as a company 
name.


On May 17, 2015 10:53:07 PM CDT, Warin <61sundow...@gmail.com> wrote:
> On 17/05/2015 3:57 PM, Stefan Baebler wrote:
> >
> > I see "Petrol" is categorized under discardedNames, but is is in
> fact 
> > a valid full name of company with chain of gas pumps in Slovenia 
> > (www.petrol.si ).
> >
> > Are there many other similar cases that would make it worthwhile to 
> > make this functionality location-aware, dependant on regions 
> > (countries, continents, languages)?
> >
> Petrol is in common use in Australia... an 'English' speaking country.
> 
> > 16. maj 2015 11.08 pop. je oseba "Mateusz Konieczny" 
> > mailto:matkoni...@gmail.com>> napisala:
> >
> > On Sat, 16 May 2015 20:07:00 +0200
> > Michał Brzozowski  > > wrote:
> >
> > > I ask non-English speakers to find anything they are sure it's
> a
> > noun
> > > and not a proper name. name-suggestions.json specifies name
> > > suggestions and filter.json specifies what "non-names" should
> be
> > > filtered.
> >
> > Sklep spożywczy (Polish for grocery store)
> > Apteka (Polish for pharmacy)
> >
> > ___
> > 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

-- 
John F. Eldredge -- j...@jfeldredge.com (615) 299-6451
"Darkness cannot drive out darkness; only light can do that. Hate cannot drive 
out hate; only love can do that." -- Martin Luther King, Jr.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD name suggestion index - asking non-English-speaking mappers to review

[John F. Eldredge]

Is there a company in Australia named Petrol, or is it simply the term for the 
fuel? As I understand it, the question is whether Petrol is valid as a company 
name (apparently 

On May 17, 2015 10:53:07 PM CDT, Warin <61sundow...@gmail.com> wrote:
> On 17/05/2015 3:57 PM, Stefan Baebler wrote:
> >
> > I see "Petrol" is categorized under discardedNames, but is is in
> fact 
> > a valid full name of company with chain of gas pumps in Slovenia 
> > (www.petrol.si ).
> >
> > Are there many other similar cases that would make it worthwhile to 
> > make this functionality location-aware, dependant on regions 
> > (countries, continents, languages)?
> >
> Petrol is in common use in Australia... an 'English' speaking country.
> 
> > 16. maj 2015 11.08 pop. je oseba "Mateusz Konieczny" 
> > mailto:matkoni...@gmail.com>> napisala:
> >
> > On Sat, 16 May 2015 20:07:00 +0200
> > Michał Brzozowski  > > wrote:
> >
> > > I ask non-English speakers to find anything they are sure it's
> a
> > noun
> > > and not a proper name. name-suggestions.json specifies name
> > > suggestions and filter.json specifies what "non-names" should
> be
> > > filtered.
> >
> > Sklep spożywczy (Polish for grocery store)
> > Apteka (Polish for pharmacy)
> >
> > ___
> > 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

-- 
John F. Eldredge -- j...@jfeldredge.com (615) 299-6451
"Darkness cannot drive out darkness; only light can do that. Hate cannot drive 
out hate; only love can do that." -- Martin Luther King, Jr.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Portal for users/casual mappers (Re: Tagging FOR the renderer)

[Daniel Koć]

W dniu 18.05.2015 12:19, moltonel 3x Combo napisał(a):


As nice as it'd be, http://osm.org/ is not trying to be
http://maps.google.com/. It's not trying to be the One True Map Portal
that caters to every needs.


I totally agree with you that One True Map Portal - in its full meaning 
- would be wrong. But it's a straw man argument, because that is plain 
impossible: our data and tools are distributed, mirrored and available 
on free licenses, so if you have some skills and the need for it, you 
can always make More True Map Portal =} (and you may even take over the 
old one, as with LibreOffice taking over OpenOffice.org)! With Google 
Maps it's not the option, of course.


You and I may not like the Google way, but they are not totally wrong 
either. The key idea is "integration". We don't need to put everything 
in one place to collaborate efficiently, but currently we are very 
disconnected as a project, so we really have no reason to be scared by 
the other extreme.


For programmers APIs, standard k/v database form or Git repositories are 
the glue; for contributors it may be OSM Wiki, iD, JOSM, lists and 
forums; but what about the people doing the most of the work - average 
mappers? Their "glue" for maps is some kind of portal and currently the 
only portal with some degree of integration for end users/casual mappers 
is our main website. They can:

1) find some names there (Nominatim or GeoNames),
2) browse the maps (5 "layers" to choose - however the name "layer" is 
wrong, because they are rather "skins" or "styles" for showing the data 
visually, and real layers would be nice to see one day!),

3) look at the data directly ("?" button),
4) leave some notes,
5) share the link to a place,
6) export the data from current view,
7) search route for car, bicycle or foot (using 2 different services for 
each of them)

8) look at the latest changes
9) ...and even edit the map without leaving the portal (iD or Potlatch)!

That is nice set of features, yet it does not look overloaded - does it? 
I think uMap would be another great tool enhancing the portal for the 
users. But at the same time things like 6) or 8) are less useful for 
them and maybe they belong to the other, "developers/advanced mappers 
portal"?



Some reasons off the top of my head, some strong and some weak :
 * The needs of contributors and users can easily conflict, and
priority is/should be given to the contributors.


OK, what are their needs then and what kind of conflict you envision 
with uMaps?


We don't know too much about real casual mappers (that's why I suggested 
making a survey/research), because they are rather plain users 
scratching their own, small itch, than advanced contributors, who are 
more like developers in turn. And most of them will never look for any 
kind of contact with the core community (BTW: it took me a few years to 
get involved, because I made a lot of simple edits and needed no 
assistance). But some of them will and they will become advanced 
contributors in the end.



 * Even without conflicts, the size of the contributor-focused todo
list means that enduser-focused features get constantly pushed back.
Help welcome.


Some of you may already know it from WeeklyOSM or the discussion on the 
Tagging list, but for the rest let me briefly quote the abstract of the 
scientific article called "Characterizing the Heterogeneity of the 
OpenStreetMap Data and Community":


"All three aspects (users, elements, and contributions) demonstrate 
striking power laws or heavy-tailed distributions. The heavy-tailed 
distributions imply that there are far more small elements than large 
ones, far more inactive users than active ones, and far more lightly 
edited elements than heavy-edited ones. Furthermore, about 500 users in 
the core group of the OSM are highly networked in terms of 
collaboration."


[ http://www.mdpi.com/2220-9964/4/2/535 ]

The most of the work in OSM is done not by the few hundreds of advanced 
users, but by much more casual mappers. So I think we should care much 
more for their work, no matter how basic it is, because if we have more 
simple users generally happy with the OSM services, we will get much 
more (small) contributions than we can ever have dealing only with core 
contributors. We just don't think of them as contributors, because we 
don't see them, but in reality they are very long kind of "tail" - 
wagging the dog probably! ;-)


I like many tools for advanced mappers, but constant pushing back end 
user needs is like having great engine only the educated engineers can 
use. The users are our ecosystem too, and the article says they are very 
powerful small-scale engineers (DIY, bricoleur) army.



 * Becoming the internet's one-stop map website would require huge
server ressources. Getting the kind of money required to run them
would require huge changes to the way OSM is run, which'd be dangerous
for OSM's freedom.


Not necessarily! We may cooperate with other projects

Re: [OSM-talk] Tagging FOR the renderer

[moltonel 3x Combo]

On 18/05/2015, Daniel Koć  wrote:
> I think the mission will be accomplished once we have it integrated with
> OSM website somehow, just like we did with routing: there were already a
> few routing services using our data, so we may not care, but for average
> user they were just not here. And so is uMap.

Routing is different in that it is immediately useful to
*contributors*, who can now check that the OSM data is correct for
routing, just like the slippymap is useful to check that the data
looks good. uMap not so much : as a contributor, I'd rather use josm,
taginfo, overpass, or even data dumps.

As nice as it'd be, http://osm.org/ is not trying to be
http://maps.google.com/. It's not trying to be the One True Map Portal
that caters to every needs.

Some reasons off the top of my head, some strong and some weak :
 * The needs of contributors and users can easily conflict, and
priority is/should be given to the contributors.
 * Even without conflicts, the size of the contributor-focused todo
list means that enduser-focused features get constantly pushed back.
Help welcome.
 * Becoming the internet's one-stop map website would require huge
server ressources. Getting the kind of money required to run them
would require huge changes to the way OSM is run, which'd be dangerous
for OSM's freedom.
 * Similarly for manpower requirements; volunteers wouldn't be enough anymore.
 * A healthy ecosystem of commercial users is important for OSM. And
they should be able to do a better job of serving the end-user, so
it's probably a bad idea to compete with their use-case.

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