Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

[Simon Poole]

By definition if you can generate it mechanically, you shouldn't be 
adding it to OSM.


Am 21.11.2020 um 15:20 schrieb Mateusz Konieczny via dev:

Is there some existing code/library/tool for generating obvious
short_name / alt_name from other tagged data?


I am implementing it right now for one of my programs
and I would prefer help in existing project rather than implement yet 
another

version of the same.

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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-dev] Restarting the EWG

[Simon Poole]

Without at least some guidance from the board on purpose and scope I see 
a real danger of this turning in to yet another iteration of "lets make 
a top ten list of stuff that might attract devs" with more money, aka 
not just GSOC, thrown in as the sole change. With the boring stuff that 
"actually needs to be done" (tm), being ignored. it isn't as if we don't 
have the experience of numerous failed EWG reboots.


Examples:

- the data privacy related work that needs on the API, the website and 
data distribution, this is probably the best defined and scoped work 
that has ever existed in the history of OSM, still it has made zero 
progress over the last three years,


- putting a system in place to manage third party sources, permissions 
to use them and provide attribution in a scaleable fashion 
(realistically just providing the mechanics for this wont be enough, as 
the clean up itself has to be organized and that could easily require 
multiple man years of clerical work).


I'm sure there are other similar items from operations and 
communications that are simply never going to make any kind of list 
without the EWG actually being made -responsible- for clearly defined 
outcomes instead of a lot of hand waving that will simply gyrate to 
projects that result in the largest amount of back patting (iD etc).


Simon

Am 19.11.2020 um 17:09 schrieb Paul Norman via dev:
The OSMF Board is looking at restarting the Engineering Working Group 
with a revised scope to include handling paid software development. 
This scope needs to be developed with existing and new volunteers, but 
my ideas are that it would include


- Google Summer of Code,
- managing development to be paid by the OSMF by contracts and grants, 
and

- collaborating with other organizations for multi-organization grants.

It would do this by by
- placing calls for proposals for paid work on topics like top ten tasks;
- accepting other proposals;
- defining an approximate distribution of OSMF funds for development 
between primary/secondary/tertiary services, external services, and 
new services;
- encouraging applications from skilled individuals who aren't 
professional developers, professional contractors, companies, and others.


Once the scope and funding distribution guidelines are defined we 
would want to start with low-risk projects involving experienced 
people who need less management.


If you are interested in changing the EWG to handle these roles, 
please let me know.



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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


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

Re: [OSM-dev] Standardized feature/tag database idea & proposal

[Simon Poole]

Frederik has already pointed out some of the relevant historic points.

On top of that there is https://github.com/osmlab/editor-presets and I 
proposed  something similar a couple of years back as a GSOC project.


I would consider the concept moot. On the one hand, while theoretically 
still possible, the iD preset scheme now has little generalisation and 
has become very UI specific, requiring to capture a lot more editor 
specific data than just a couple of years back if you wanted the output 
to be similar to the original. On the other hand, not just because of 
the demographics, but also because of the OSMFs involvement, like it or 
not, the iD presets are the law of the land and anything else is simply 
irrelevant. That is not a statement about quality (I would maintain that 
my presets continue to be the best curated set of presets), but about mass.


You should have also given my talk at SOTM 2018 a look 
https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/


In any case both iD and Vespucci use taginfo and associated information 
to synthesize parts of, or complete presets. Vespucci as part of an 
explicit search process, iD built in to how their presets work. For a 
number of reasons the results are at best mixed, but clearly could be 
improved with some work on taginfo. I would consider this a better way 
forward than starting something new.


Simon

Am 15.11.2020 um 19:14 schrieb Seth Deegan:

_Idea_
Has anyone ever thought of creating an official database that stores 
all of the approved and in-use tags/features in OSM?


_Reasoning_
This could allow the editors (iD and JOSM, StreetComplete, GoMap!) and 
data consumers (osm-carto,. Mapbox etc.), to easily stay up-to-date 
with new features, without requiring their developers to browse the 
Wiki etc.


_Examples_
Both iD and JOSM have their own preset file/repo and are independent 
of each other. Creating a database that could be used as a dependency 
of both that would store these feature presets and their fields means:

 - Both are up-to-date and in-sync
 - Adding new presets could be done automatically by retrieving and 
parsing data from the DB.


Creating applications that use OSM data can be hard and 
time-lengthened by requiring developers to browse the Wiki to find all 
of the features and their keys and values. Having a database that they 
could easily get the keys they want, their values, etc. would 
*significantly* allow greater OSM developer potential.


_Specifics_
The specifics as to how this database would be arranged such as to 
where presets/fields/tags/features go has not been thought of yet. I 
just wanted to ask if this has ever been proposed before. If someone 
would like me to make a DB layout to help them better understand what 
I'm proposing, I'd be happy to do so.


_My pre-DB construction proposal _
Before any type of database is made, one would would *construct a 
dedicated page structure on openstreetmap.org 
 *that would display and be in-sync with all 
of the Features from the DB in a format similar to the Wiki, and then 
*remove all of the features from the Wiki altogether.*

*
*
*Why?* If you see in _Compiling and distributing the DB_ below, a Wiki 
bot is going to be required to get all of the pages for all of the 
already-standard features. Most of the features' pages do have a 
similar structure as to how they are arranged (template that shows 
what elements they use, Keys' values and their descriptions are stored 
in a table, etc.), however these pages would be /impossible/ to parse 
thoroughly with a computer and are going to require team of humans to 
get all of their data.


New features that are proposed and approved after the database would 
be created would require them to be hand-added. Making a standard way 
to propose and approve new features on a new part of the website with 
formatting constraints and database-syncing abilities that MediaWiki 
cannot offer, would mean that the DB would never have to be physically 
touched again and ensure greater long-term DB management efficiency.

*
*
*So why basically delete one of the primary functions of the Wiki and 
create a new system on openstreetmap.org ?*
I recently have got into the OSM community head-on in the past two 
months. I have never really contributed to Wikipedia or any other site 
that uses the MediaWiki website format so learning about how to 
contribute and get around the OSM Wiki took time (learning about the 
proposal process, Templates, talk pages, formatting, the list goes on 
and on...). It also made me realize that this could discourage new 
users from ever looking into the depths of OSM or even finding the 
Wiki at all. The WikiMedia interface is not the prettiest either. It 
can take time for new users to explore and find what they are looking 
for.
(Also, this would mean moving the proposal process over to osm.org 
 too)

Re: [OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

[Simon Poole]

I think you are missing

"Only zoom 0 to 8 has been implemented so far. I started at zoom 0 and
am working my way down."

Simon

Am 26.05.2020 um 10:42 schrieb Maarten Deen:
> On 2020-05-26 10:15, Paul Norman via dev wrote:
>> On 2020-05-25 1:15 a.m., Maarten Deen wrote:
>>> Still, it looks to be a very simplified subset of the complete data.
>>> So I'd be interested to see how this works on a full dataset.
>>
>> No, it has the full data except for admin boundaries and bay/straight
>> names on zoom 7 and 8. When you compare it to OpenStreetMap Carto
>> they're pretty similar. There are some labeling differences with sizes
>> of labels and when labels come in, but those don't have anything to do
>> with performance or size.
>
> No, that's not what I'm seeing. I am seeing very basic and rectangular
> landuses, obviously simplified, along with waterways, railways,
> motorways, trunk, primary secondary roads and they too have been
> simplified, to the extent that parallel ways on motorways are now
> crossing eachother.
>
> This is in my area:
> https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html#12.14/51.36196/6.08322
> https://imgur.com/a/WcYlVUc
>
> Regards,
> Maarten
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Freely accessible aerial imagery tileserver?

[Simon Poole]

Naturally there are free tiers with the goog and so on, but that
requires some warping of "freely accessible" to fit the definition.


Am 19.02.2020 um 13:23 schrieb Nick Whitelegg:
>
> Hello Simon,
>
> OK - thanks - just thought I'd ask just in case something existed but
> was obscure and hard to find.
>
> Thanks,
> Nick
>
>
> --------
> *From:* Simon Poole 
> *Sent:* 19 February 2020 10:44
> *To:* dev@openstreetmap.org 
> *Subject:* Re: [OSM-dev] Freely accessible aerial imagery tileserver?
>  
>
> The very short answer, if you are referring to a global "high
> resolution" imagery mosaic, is "no".
>
>
> Am 19.02.2020 um 11:36 schrieb Nick Whitelegg:
>> Hi,
>>
>> Just wondering if there are any 'XYZ tile format' freely available
>> aerial imagery tileservers, other than low-resolution ones such as
>> Landsat.
>>
>> Have checked https://wiki.openstreetmap.org/wiki/Aerial_imagery
>> <https://wiki.openstreetmap.org/wiki/Aerial_imagery> and it lists a
>> few, but I'm not sure any are freely available at high resolution and
>> with global coverage. Bing, I think, is only licensed for use in OSM
>> editors and not general OSM applications.
>>
>> I'd like to use it for my own (FOSS) web-based application to overlay
>> aerial imagery and OSM data on a 3D terrain.
>>
>> Thanks,
>> Nick
>>
>>
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] Freely accessible aerial imagery tileserver?

[Simon Poole]

The very short answer, if you are referring to a global "high
resolution" imagery mosaic, is "no".


Am 19.02.2020 um 11:36 schrieb Nick Whitelegg:
> Hi,
>
> Just wondering if there are any 'XYZ tile format' freely available
> aerial imagery tileservers, other than low-resolution ones such as
> Landsat.
>
> Have checked https://wiki.openstreetmap.org/wiki/Aerial_imagery
>  and it lists a
> few, but I'm not sure any are freely available at high resolution and
> with global coverage. Bing, I think, is only licensed for use in OSM
> editors and not general OSM applications.
>
> I'd like to use it for my own (FOSS) web-based application to overlay
> aerial imagery and OSM data on a 3D terrain.
>
> Thanks,
> Nick
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] planet.osm.org is verry slow

[Simon Poole]

Am 25.01.2020 um 22:19 schrieb marc marc:
> Le 25.01.20 à 21:43, Simon Poole a écrit :
>> Am 25.01.2020 um 21:12 schrieb marc marc:
>>> is there a convenient way to update a pbf to exactly the same diff as
>>> osm.org? and/or add the state.txt of the pbf produced on osm.org?
>>> this would allow to have the same pbf mirrored on other sites without
>>> having to download and/or encode the same thing several times
>> The answer is likely no, because I don't believe there is a guarantee
>> that the planet dump contains exactly the commits of a certain set of
>> diffs,
> the planet dump is done from the db itselft and not using by a cascade
> of diffs (min->hourly>daily>weekly) ?
> or maybe a special diff between planet dump.

Yes the dump works via a completely different mechanism.

The problem is actually fixable (not expecting a lot of enthusiasm for
it though), we could post creating the dump run an update from a
specific diff prior to when the dump started on the dump before
publishing. Doing this wouldn't guarantee that the binaries of a
parallel updated planet file are the same, but they would have the same
contents.

>> But that doesn't matter in a practical sense
> it avoids having different files between mirrors, which is quite
> annoying if a bug occurs on one variant and not on another depending
> on the "mirror".
See above.
>
>> In any case there is no argument to be made for the ~1'000 downloads 
>> that start shortly every week after the plant dump has been produced, 
> I agree.
> maybe a rate limit "1st full speed" or "full speed for mirror"

AFAIK that is already the case.

Simon

>> and of which for weird reasons 25% are actually
>> downloading the compressed XML file (which is 30% larger).
> there are probably some tools that don't support pbf (for example
> osmfilter (I don't mind too much, I do an osmconvert before, but I guess
> this extra step is not done and/or not available and/or not known by
> other people).
>
>> Simon
>>
>>> Le 25.01.20 à 18:34, marc tobias a écrit :
>>>> Wolfram, who asked about the bandwidth, is already running a mirror
>>>> https://download.bbbike.org/osm/planet/
>>>> (listed on https://wiki.openstreetmap.org/wiki/Planet.osm#Downloading)
>>>> so downloading it every week is likely trying to update his mirror.
>>>>
>>>> marc tobias
>>>>
>>>>> Message: 2
>>>>> Date: Sat, 25 Jan 2020 11:46:20 +0100
>>>>> From: Simon Poole 
>>>>> To: dev@openstreetmap.org
>>>>> Subject: Re: [OSM-dev] planet.osm.org is verry slow
>>>>> Message-ID: <4f5c3f2c-f3c9-0545-0dd2-98df390e4...@poole.ch>
>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>
>>>>> Yes, there are now bandwidth restrictions on connections to
>>>>> planet.openstreetmap.org because the usage had skyrocketed and outgoing
>>>>> bandwidth was completely saturated.
>>>>>
>>>>> But the obvious question is: why are you even trying to download the
>>>>> full planet twice within a fortnight? Particularly given the file can
>>>>> easily be updated in situ.
>>>>>
>>>>> Simon
>>>> ___
>>>> dev mailing list
>>>> dev@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/dev
>>>>
>>> ___
>>> dev mailing list
>>> dev@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] planet.osm.org is verry slow

[Simon Poole]

Am 25.01.2020 um 21:12 schrieb marc marc:
> is there a convenient way to update a pbf to exactly the same diff as
> osm.org? and/or add the state.txt of the pbf produced on osm.org?
> this would allow to have the same pbf mirrored on other sites without
> having to download and/or encode the same thing several times

The answer is likely no, because I don't believe there is a guarantee
that the planet dump contains exactly the commits of a certain set of
diffs, so I suspect you are asking for something that the planet dump
itself doesn't actually provide  (Matt Amos would be able to give more
information on that, see https://github.com/zerebubuth/planet-dump-ng).
But that doesn't matter in a practical sense, as you will always roll
back a bit the 1st time you start applying diffs and from then on your
planet will exactly contain a diff or not.

There is perhaps an argument to be made that actual mirrors should make
a binary copy. In any case there is no argument to be made for the
~1'000 downloads that start shortly every week after the plant dump has
been produced, and of which for weird reasons 25% are actually
downloading the compressed XML file (which is 30% larger).

Simon

>
> Le 25.01.20 à 18:34, marc tobias a écrit :
>> Wolfram, who asked about the bandwidth, is already running a mirror
>> https://download.bbbike.org/osm/planet/
>> (listed on https://wiki.openstreetmap.org/wiki/Planet.osm#Downloading)
>> so downloading it every week is likely trying to update his mirror.
>>
>> marc tobias
>>
>>> Message: 2
>>> Date: Sat, 25 Jan 2020 11:46:20 +0100
>>> From: Simon Poole 
>>> To: dev@openstreetmap.org
>>> Subject: Re: [OSM-dev] planet.osm.org is verry slow
>>> Message-ID: <4f5c3f2c-f3c9-0545-0dd2-98df390e4...@poole.ch>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Yes, there are now bandwidth restrictions on connections to
>>> planet.openstreetmap.org because the usage had skyrocketed and outgoing
>>> bandwidth was completely saturated.
>>>
>>> But the obvious question is: why are you even trying to download the
>>> full planet twice within a fortnight? Particularly given the file can
>>> easily be updated in situ.
>>>
>>> Simon
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] planet.osm.org is verry slow

[Simon Poole]

Yes, there are now bandwidth restrictions on connections to
planet.openstreetmap.org because the usage had skyrocketed and outgoing
bandwidth was completely saturated.

But the obvious question is: why are you even trying to download the
full planet twice within a fortnight? Particularly given the file can
easily be updated in situ.

Simon


Am 25.01.2020 um 11:29 schrieb Wolfram Schneider:
> I wanted to download the latest planet from planet.osm.org and the
> download rate is  less than 450KByte/s. In the past I got
> 30-60Mbyte/s. It takes now more than 36 hours to download the planet
> (was 15min). All mirrors are outdated, you have to wait until Sat
> morning to see a new planet.osm.pbf file.
>
> I tried to download the planet from different locations, IP addresses
> and clients - it is always slow per connection. It seems that the
> slowdown is on purpose by a config change, not an overloaded machine.
>
> Two weeks ago everything was fine. Does anybody has an idea whats happens 
> here?
>
> Thanks, Wolfram
>
> --
> Planet.osm extracts: https://extract.bbbike.org
> BBBike Map Compare: https://mc.bbbike.org
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Google-free phones

[Simon Poole]

Just as a additional point: it is a specific design goal to not require
any google services or non-open libraries for Vespucci. Unluckily that
doesn't mean that you are not completely at the mercy of the goog
anyway, see for example the for all practical purposes deprecation of
all devices with pre-Android 4 OS versions and the likely soon to happen
further  dumping of anything lower than 4.4.

Simon

Am 26.11.2019 um 10:16 schrieb Frederik Ramm:
> Hi,
>
> On 26.11.19 08:57, Andrew Hain wrote:
>> How well do OSM apps work on Google-free Android phones?
> Don't see what the issue should be... I've personally run OsmAnd,
> Vespucci, and OsmTracker on a non-Gapps Lineage phone and they all work
> without a glitch.
>
> Bye
> Frederik
>



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

Re: [OSM-dev] Issue with way id 742619958 / changeset 76711047 from 2019-11-06T15:32:03Z (Invalid layer value)

[Simon Poole]

Am 08.11.2019 um 17:41 schrieb Michael Reichert:
>
> strings (up to 256 characters). 
255



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

Re: [OSM-dev] Use of OSM API for non-editing third party applications

[Simon Poole]

There is a large amount of precedent, for example mapillary, maproulette
and lots that I've forgotten. So the answer is likely that while the
website-devs are not in love with it, it is perfectly acceptable.


Simon


Am 01.08.2019 um 13:52 schrieb Nick Whitelegg:
>
> Hi,
>
>
> I'm just asking something which was raised as an issue in my Gitlab
> repository for OpenTrailView (www.opentrailview.org
> ; fully FOSS 360 panorama site which
> uses OSM ways to connect panoramas together).
>
>
> The person who raised the issue requested that OSM logins be used on
> OpenTrailVIew rather than (as currently) its own login system. I
> suspect the reason is security-related as it allows users to use an
> existing trusted authentication system.
>
>
> As OpenTrailView does not include provision for editing OSM data, I
> suspect the answer is no - but is it acceptable for third-party
> OSM-related sites which do not edit the data to 'piggyback' on OSM's
> authentication system like this?
>
>
> Thanks,
>
> Nick
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] API Basic Authentication

[Simon Poole]

See https://github.com/zerebubuth/openstreetmap-cgimap/issues/189

Your app should be working again right now as Tom has reverted back to
the Rails implemetation, still you should likely be using OAuth to start
with.

Simon

Am 30.05.2019 um 21:33 schrieb Colin Smale:
>
> A (private) program I use which accesses the OSM API has stopped
> working since the last time I used it, a couple of weeks ago.
> Read-only calls to the API, including a (proven correct)
> Authentication header are now failing with 401 Unauthorized, with the
> returned body indicating a problem with the username/password. The
> same call without the Authorization header succeeds. I swear nothing
> has changed on my side; double-checking the auth header with Fiddler
> shows the username/password I expect, and I can still logout/login
> using these values (which I haven't changed).
>
> Is there anything going on, or has anything changed on the API, that
> may be causing this?
>
> Sample URL: GET on https://api.openstreetmap.org/api/0.6/relation/8465619
>
> I know I can just remove the authentication - it was added for "future
> use" anyway - but why has it suddenly broken?
>
> Thanks,
>
> Colin
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] osm.org groups

[Simon Poole]

See https://github.com/openstreetmap/openstreetmap-website/pull/297

Unluckily nobody has been motivated enough to do this on their own time,
and the OSMF has been steadfastly ignoring any suggestions to undertake
any effort to improve the website by spending money.

With other words: holding your breath for this feature is not recommend.

Simon

Am 30.04.2019 um 22:48 schrieb Svetlana Tkachenko:
> Hi Dmitry
>
> Perhaps these features can be useful for the Libreplanet wiki as well.
>
> Svetlana
>
> Дмитрий Киселев  > wrote:
>> Hi everyone,
>> I know that making a good working groups is hard and only facebook
>> succeed in that, and that's why we don't have any way to group users
>> or friends at osm.org 
>>
>> But can we have at lest something, maybe not so great as slack or fb, 
>> but anything to group contacts in friends list and create some sort of 
>> local mailing list or group discussions?
>>
>> I'm living in a third city since I've start to edit OSM so there are
>> local friends in my list, friends from the places where I used to
>> live before, some of the contacts from conferences all in one list. 
>>
>> I'm trying to get in touch with local mappers around me, and writing
>> 30+ letters to invite people the meetup is quite cumbersome.
>>
>> So as a first step, can we create some way of grouping friends in a
>> contact list?
>> As a second step, can we discuss how to invite a group of people to
>> discuss something all together without third party tools?
>>
>> -- 
>> Best regards,
>> Dmitry
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] Change Tile server on openstreetmap.org

[Simon Poole]

You might want to read
https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN first.

Simon

Am 22.04.2019 um 22:31 schrieb Moritz Fromm:
> Hi,
>
> I am running an cache proxy for the OSM Tiles server. It's used in
> another Project for an Leaflet map and it is considerably faster and
> more responsive than the default {a-c}.tile.openstreetmap.org,
> absolutely no offense there it's free and just fine overall I guess. I
> would really like to use my cache proxy, and if the Server can handle it
> offer it to others, on openstreetmap.org. This would both
> considerablyincrease a users experience while also reducing the load on
> the original tiles server. My plan is to do so using an browser
> extension. I have not found uncompressed javascript code for
> openstreetmap.org from which to extract the functions to call in order
> to change the tiles server, What I have found from decompressing the
> assets-.js is: 
>
>> L.OSM.TileLayer = L.TileLayer.extend({
>>     options: {
>>     url: "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png";,
>>     attribution: '\xa9 > href="https://www.openstreetmap.org/copyright";
>> target="_blank">OpenStreetMap contributors'
>>     },
>>     initialize: function(t) {
>>     t = L.Util.setOptions(this, t),
>> L.TileLayer.prototype.initialize.call(this, t.url)
>>     }
>>     })
> I believe this to be where the map is initialized, but executing the
> same pice of code with my domain is not working. I am wondering:
>
>  1. was is the least stupid way in order to change the tiles after the
> Page has been loaded?
>  2. Is there any better way than writing a plugin for that job?
>
>
> Greetings,
> Moritz
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] iD news - 2.12.0 released 🎉

[Simon Poole]

I suspect Frederik was more concerned about the consequence that it
makes place names essentially uneditable.

Simon

Am 10.12.2018 um 13:48 schrieb Andrew Harvey:
> On Mon, 10 Dec 2018 at 19:02, Frederik Ramm  wrote:
>> On 10.12.2018 03:14, Bryan Housel wrote:
>>> iD now displays linked data if a feature has a wikidata tag, and will
>>> protect fields like name and brand from direct editing.
>> Can you elaborate on the logic behind this a bit more?
>>
>> On first reading it sounds like if I set a wikidata tag on something, iD
>> will load name and brand from wikidata and not allow editing of those
>> fields but that certainly can't be right. Which fields exactly are
>> protected, what does protection mean, and by what is this protection
>> triggered?
> If you search for a preset with a brand, eg. McDonalds and select that
> it will populate:
>
> amenity=fast_food
> cuisine=burger
> name=McDonald's
> brand=McDonalds
> brand:wikidata=Q38076
> brand:wikipedia=en:McDonald's
>
> Then the name field is locked from editing in your session so you
> can't change it, unless you go down to the advanced "All tags" section
> where you can edit any of these locked free form tags.
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Various types and means of account blocks

[Simon Poole]

As way of a clarification: the LWG was not proposing to block children
from answering on changeset comments (given these are public and not so
easily misued), but not allowing access to the blog and the internal
message system.

Simon


Am 24.09.2018 um 20:22 schrieb Michael Reichert:
> Hi Frederik,
>
> Am 24.09.2018 um 17:57 schrieb Frederik Ramm:
>> Is the opposite true as well - would/should someone given a cool-off
>> period for being a dick in a discussion still be allowed to do mapping?
> No. Anyone who is able to edit the map data should be able and has to
> answer sensible questions.
>
>> Should a normal user block perhaps simply come in two flavours, "block
>> mapping only" and "block all"?
>>
>> It has been suggested that blocking *all* communication functions might
>> be problematic because one thing you might expect from someone you have
>> blocked is that they apologise, or set something right, which they might
>> not be able to do without the ability to write messages.
> If we implement the new block type proposed by ika-chan!, the DWG can
> place a type 1 block (editing block) on the account and tell him to
> aplogoise. If the user fails to do so, it's a sign of bad intentions and
> a full block can be placed.
>
>> Do we need a full array of permissions - "can change user name", "can
>> edit own user page", "can write personal messages", etc. - and the
>> ability to short-time suspend any and all of them?
>>
>> Thoughts are welcome.
>>
>> This also ties in somewhat with a separate discussion, on how a
>> prerequisite for allowing children on the platform might be that we can
>> disable the "social" functions of an account. In that case it would not
>> be a short-term block, but a whole class of accounts that can edit, but
>> not participate in discussions (for their own protection). I'm not sure
>> that can work at all (given that the ability to contact a mapper is very
>> important to us). Maybe such accounts would have to be linked to a
>> "responsible" parent account who then gets the messages...
> I think that any mapper should have the possibility to ask another
> mapper any question on their edits. Currently, we often place a 0-hour
> block on accounts who fail to respond and continue editing. What shall I
> myself as a mapper do if the user whose edits look strange cannot answer
> my question why he deleted the restaurant? Shall he/she restore it
> because the child does not respond?
>
> The concept of hiding minors from communications might work if they are
> asked/told to map just due to their ability to draw geometries, e.g. in
> an enclosed system or for mapping a few villages in an area where no
> data has been before and nobody else is mapping. But once they edit
> existing data, "conflicts" (questions and comments) with the community
> will arise.
>
> It might be possible to solve these issues but figuring out solutions is
> up to those who need minors below 16 years mapping.
>
> Best regards
>
> Michael
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] question about add way to openstreetmap by GPX automatic

[Simon Poole]

You probably don't want to use the tracks directly to add roads to OSM
(you would only want to do this once in any case). Definitely they could
be useful for detecting which roads are missing, and, if the available
aerial imagery  isn't good enough for actually adding any missing roads.

Can you indicate where the city is?

Simon


Am 14.09.2018 um 14:33 schrieb zhangy...@lewaimai.com:
> my ios app has 10,000 users in one city, and they wii collect
> the trajectory in gpx format, i want to add way to  openstreetmap use
> their gpx trajectory.
>
> there will be almost 100,000 gpx files one day, so it is not possible
> to edit map manual by software such as JOSN.
>
> I want to know if I can product ways accord to the 100, gpx files
> automatic，I need a C++ library which can do this，can anyone help me
> please？
>
>
>
> 
> zhangy...@lewaimai.com
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] New OSM Data Export: Deleted User Account IDs

[Simon Poole]

No and we wouldn't publish that on an account by account base for rather
obvious privacy reasons.

Simon


Am 07.09.2018 um 19:35 schrieb Martin Koppenhoefer:
> In this context it would be interesting to get an idea how many people
> asked themselves for deleting their own account. Does the list contain
> a reason for the account deletion?
>
> Cheers,
> Martin
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

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

[Simon Poole]

Come on, you're  leaving us out on a limb. Now we want to know the world
leader in relation membership :-).


Am 27.08.2018 um 01:00 schrieb Frederik Ramm:
> Hi,
>
> in the course of a discussion over on talk-gb, I wanted to find out
> which ways have the highest number of relation memberships. In case
> someone is interested, here's how to do it with Osmium and Perl.
>
> 1. create this Perl script which reads "opl" ascii format
>
> #!/usr/bin/perl
>
> while(<>)
> {
> next unless /boundary/;
> s/.* M//g;
> foreach (split(/,/))
> {
> my ($a,$b)=split(/@/);
> $mem{$a}++;
> }
> }
>
> $i=0;
> foreach (sort { $mem{$b}<=>$mem{$a} } keys(%mem))
> {
> printf "%d %s\n", $mem{$_}, $_;
> last if ($i++>100);
> }
>
> 2. feed an .osm.pbf file into it:
>
> osmium cat some-file.osm.pbf -trelation -fopl | perl myscript.pl
>
> I ran this for England and found a small number of ways that were
> actually in over 100 different (bus route) relations ;)
>
> If you like Python, you could of course do the whole thing in one go
> using the PyOsmium library
>
> Bye
> Frederik
>




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

Re: [OSM-dev] Difficulty fetching data from API in own app, but not browser

[Simon Poole]

IMHO I would 1st verify that you are actually generating the same query
(and the one your expect) with wireshark (running the app in the
emulator) and that what is happening is actually a time out. It seems
really really really unlikely to me that you are running in to the rate
limiting.


2x2km can naturally be a lot of data, in particular if you have largish
relations in the area (even if you are not downloading all the members).


Simon


Am 23.07.2018 um 18:19 schrieb Nick Whitelegg:
>
>
>  Digging a bit more, it looks like the API will reject a request
> if you make it relatively soon after the first; is this correct?
>
> Is there a specific time limit between requests, i.e. you can only
> make requests every X seconds (if so, I can code this into my app)?
>
>
> To make it absolutely clear - I am using the API for editing purposes.
> Specifically, the feature I'm testing at the moment allows you to
> download data from the API (2x2km square centred on current location),
> select ways and add/modify a designation tag.
>
>
> Thanks,
>
> Nick
>
>
>
> 
> *From:* Nick Whitelegg 
> *Sent:* 23 July 2018 16:50:14
> *To:* dev@openstreetmap.org
> *Subject:* [OSM-dev] Difficulty fetching data from API in own app, but
> not browser
>  
>
>
> Hi,
>
>
> Currently experiencing some inconsistent behaviour with the API in
> which fetching via the browser gives a response,
>
> but my own app ('MapThePaths', part of a project intended to help map
> footpaths and edit designation tags in the UK) frequently hangs
> waiting for a response.
>
>
> MapThePaths uses the osmapi (Tobias Zwick) to fetch data.
>
>
> Is there any reason currently why the API might be responding to
> standard web browsers but not custom apps?
>
>
> FWIW my app should be reporting itself as "MapThePaths Android app"
> and I have just (around 16:35-16:40 UK time) made three unsuccessful
> requests with the bbox:
>  -0.7295872761598865,51.09355911139382,-0.7005316007485753,51.11122494429744.
>
>
> Sometimes, however, my app is retrieving data from OSM successfully
> (perhaps 60-70% of the time).
>
> No exception is thrown - just looks like a timeout.
>
>
> I also observed similar behaviour 'in the field' yesterday afternoon
> when I was using the app in the countryside. The app could talk to my
> own API on mapthepaths.org.uk successfully but could not communicate
> with the OSM API.
>
>
> Is this simply related to the issues with the OSM API at the moment
> related to moving to another server?
>
>
> Thanks,
>
> Nick
>
>
> *Nick Whitelegg*
> *Senior Lecturer in Computing (Internet)*  *|* School of Media Arts
> and Technology
> Southampton Solent University  *|* RM424 *|* East Park Terrace *|*
> Southampton SO14 0YN
> T: 023 8201 3075 *|*E: nick.whitel...@solent.ac.uk
> *|*W: solent.ac.uk
> 
>
> Disclaimer 
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] GDPR implementation on planet.osm.org

[Simon Poole]

Just as a clarification:

- we do intend to have ToS for both the website and the API, that among
other things address privacy aspects (a 1st draft went out for comment
to the OSMF board and the WGs today, and if no major blockers are found
will be available for public comment rsn).

- I expect that access to the "raw" data including user data will only
be possible with a login and correspondingly agreeing to the ToU

- use of OSM data within the limits of the ToU will likely not cause any
privacy related issues, so the barrier of having an OSM account and
agreeing to the ToU would seem to be enough for the typical use of
contributors,

- use of the data as in say osmcha, Pascals services and so on, which
would not be covered by the ToU, does raise privacy issues and such
consumers/distributors of OSM data are expected to act as independent
controllers as already outlined. Essentially what we can offer as
support there is the already mentioned list of deleted accounts, and
providing all contributors with a list of data controllers to fulfil the
obligations in GDPR Art. 14.

As said some details still need to be worked out, so I wouldn't take it
as gospel right now.

Simon


Am 20.06.2018 um 20:16 schrieb Roland Olbricht:
> Hi,
>
> brief and frank: The suggested way that users of Overpass API have to
> sign up as OSM users would cause a downtime of some months and a
> development backlog of more than a year, or kill the project entirely.
> Because this sounds harsh, I will explain that further down.
>
> The key point is: please do not bind information intended for data
> processors to OSM user accounts.
>
>> The only alternatives I can see would be:
>>
>> 1. Stop distributing who-did-what-when information
>> [...] it would create a privileged class inside OSM
>> [...] 2. Take the view that distributing the data is what we do and
>> tough
>> luck, you've signed up to it.
>
> As Simon has pointed out there is another alternative. And I have
> understood so far the OSMF that way wanted to follow that way:
>
>> as has been outlined before, 3rd parties using OSM data with user data
>> will be acting as independent data controllers and will not be
>> processing data on behalf of the OSMF (which would require a DPA and all
>> the associated complications). They will have to make their own
>> determinations on how to deal with the situation. We will  provide some
>> support to such entities to help them fulfil their legal obligations
>> (for example a list of deleted users), but that's it.
>
> In particular, data processors do a much better job if they do not
> deal with OSM accounts at all, avoiding having and triggering extra
> who-viewed-what data.
>
> Most important, privacy relevance varies heavily with context. Hence I
> will and should inform users about different risks than the OSMF, and
> HDYC may again decide to stress other aspects. A central ToU cannot do
> that. Also, for that reason the GDPR is a law and not a suggestion for
> a contract, and the OSMF decided to handle it as such.
>
> To give an analogy, think of blades. It is forbidden by law to injure
> or kill someone, and blades of any kind do pose a risk. Kitchen knives
> can be used to stubb someone, but nobody every got stubbed with a
> kitchen blender. By contrast, user may harm themselves when using a
> kitchen blender. For that reason, you should be informed about the
> blades in the kitchen blender's manual, but no knife salesman in the
> world would require you to sign a contract not to stubb someone else
> with the knife. Conversely, giving too detailed information what
> approaches of stubbing are physologically risky and which are harmless
> could be abused as how-to-stub instructions.
>
> Taking GDPR serious means every data processor must decide which use
> cases they make simple, which use cases they make hard, and tailor the
> documentation according to that. For example, for that reason Overpass
> API has no feature to track all actions of a single user. I have
> proposed a declaration tailored to Overpass API on the FOSSGIS list
> (the FOSSGIS is sponsoring the server operations), and I would prefer
> to go forward with that one. A central ToU does not help, hence having
> it ticked or not is of no interest to the data processor.
>
> Then there is the problem that regardless whether you expect that OSM
> users will read or just tick the box, you have downsides:
> - If you expect that users do read the ToU then we will scare away
> users that just signed up to fix a POI and find themselves scrolling
> through pages of legalese on a mobile phone
> - If you do not expect that users read the ToU then the bad guys in
> particular won't do, and no judge ever would count that as an
> appropriate technical protection of data
>
> In addition, this is stealing users' attention from more important
> matter. Our contributor terms have quite some content and that so for
> a reason.
>
> On the technical side, things are even worse. The elephant

Re: [OSM-dev] GDPR implementation on planet.osm.org

[Simon Poole]

Am 20.06.2018 um 16:50 schrieb Jochen Topf:
> On Wed, Jun 20, 2018 at 03:08:52PM +0200, Frederik Ramm wrote:
>>> instead of arguing that this data needs to be public for everyone.
>> Any judge will laugh at you if you say that the information that user
>> John Smith has mapped something at 4:23 on the 3rd of January needs to
>> be public for everyone. Why would it, outside of a very narrow number of
>> QA related use cases?
> If you publish a book you can't later force everybody who bought the book
> to remove the author either. 
Wrong analogy.

Nobody is asking that pure consumers of OSM data to hunt through their
data and remove deleted users ids and display names,  but just as a 
book could be removed from circulation by the author/publisher etc. and
they could very well ask downstream book store and distributors to stop
selling and distributing the book, we and downstream distributors of the
data  need to stop distributing and publishing user data when the user
wants it deleted. To reuse your analogy we are removing the authors name
from new books sold and allowing it to otherwise remain in circulation.

Simon


> The law shouldn't be applicable to what we
> are doing here and we should argue that it isn't. If we bend ourselves
> backwards to try to comply to something that doesn't fit and can't fit,
> we have already lost the political case and the legal case, and broken
> the openness this project needs.
>
> Jochen




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

Re: [OSM-dev] GDPR implementation on planet.osm.org

[Simon Poole]

Am 20.06.2018 um 07:58 schrieb Jochen Topf:
> [ a lot of stuff that is (technically) reasonably easy deleted ]
>
> On Tue, Jun 19, 2018 at 10:54:07PM +0200, Frederik Ramm wrote:
>> 3a. issue guidelines about what you are allowed to do with the user data
>> files,
>> 3b. ensure that everyone who has an OSM account agrees to these
>> guidelines one way or the other,
> This is the part that's not easy and where there is a lot of important
> detail missing. You have to get everybody to agree, which is not going
> to happen. So you have to add some flag to the database telling the
> system whether you are allowed to download or not. You probably have to
> change rules in the future so you have to make this generic, keeping
> information about who clicked through which version of the rules. So you
> are generating more information you are tracking with each user, more
> personal information for which you need consent from the user. 
A) we are not asking for consent, B) yes, we will need an extra flag for
ToU acceptance.

But in any case up to here this is a fairly accurate description of what
the intent is.

> All of
> this needs to be tied in the OAuth stuff and it has to be done in a way
> that 3rd party services using OSM data can ask *their* downstream users
> to identify in the same way which allows OSM to track everybody who uses
> the full OSM data everywhere adding more personal data to keep and to
> explain to users and get permissions from users for.
Nope:
-  anybody using OSM data without the user data is not going to be
affected at all and they don't need to change anything (I've seen
indications that this could be more than 99% of all users downloading
OSM data)
- as has been outlined before, 3rd parties using OSM data with user data
will be acting as independent data controllers and will not be
processing data on behalf of the OSMF (which would require a DPA and all
the associated complications). They will have to make their own
determinations on how to deal with the situation. We will  provide some
support to such entities to help them fulfil their legal obligations
(for example a list of deleted users), but that's it. Naturally the GDPR
applies to such entities completely regardless of what we say, since the
GDPR just happens to be the law. There are still some open questions on
exactly what needs to be done, in particular wrt transfers of data to
countries where the EU hasn't made an equivalence determination, but we
are slowly firming that up.

Simon
> Please stop this nonsense now!
>
> Jochen




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

Re: [OSM-dev] GSoC

[Simon Poole]

Hi Nafiz

Where you thinking of a specific app? There is no "Android version of
OSM" as such, just a number of applications for different purposes
(routing, map display, editing).

Simon


Am 10.03.2018 um 21:18 schrieb nafiz Chowdhury:
>
> Dear sir,
> I have a project suggestion for Google Summer of Code. This is more of
> an utility feature for phone users of OSM. Could a location reminder
> feature be added to the Android version of OSM where a user can set a
> location for a task so that whenever the user is in that region, they
> will be given a notification.
> Can this be considered as a valid project? If so, what libraries would
> I have to look into to implement something like this. 
> Thanks. 
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Read-only API calls, fair usage

[Simon Poole]

IMHO it boils down to one extra API call per edit made in a maproulette
context(on top of a minimum of two API calls (if the editor is doing
things properly that is actually three), so likely it is simply a bit of
added noise, depending on how expensive
https://wiki.openstreetmap.org/wiki/API_v0.6#Query:_GET_.2Fapi.2F0.6.2Fchangesets
is (which depends on which indices exist on the table etc).

I suppose the timing might be a tiny bit tricky due to replication
delays and against which DB server the query runs in the end.

Simon


Am 20.02.2018 um 01:44 schrieb Martijn van Exel:
> Hi, 
>
> We’re thinking about adding task completion validation to MapRoulette. The 
> basic premise is this: a user completes a task in MapRoulette, and marks it 
> as ‘Fixed'. MapRoulette would then make an OSM API call for recent changesets 
> by that same user, and make a best effort at matching a recent changeset to 
> the task they say they completed. This would mean one call to 
> https://www.openstreetmap.org/api/0.6/changesets?user= for every stated Fix 
> in MapRoulette. Currently the number of fixes is in the thousands per week, 
> but that may grow as we roll out the new version of MapRoulette.
>
> Would you consider this a reasonable use of the OSM API?
>
> Martijn
>
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] Working with OSM data with less or no metadata

[Simon Poole]

Am 16.02.2018 um 14:24 schrieb Martin Koppenhoefer:
>
>
> I don't share the interpretation that OSMF processes personal data
> (besides the e-mail addresses and maybe IP addresses used by its
> contributors, which are neither distributed nor public), because I
> don't think that our mappers can be identified with the data and
> metadata of their contributions. I.E. they are not identifiable
> natural persons because they cannot be identified, directly or
> indirectly.

Naturally we have the case of the licence change which proved the exact
opposite.

But that doesn't matter in any case as the GDPR does not require that
what qualifies as personal data be directly associated with an
individual by personal name (which seems to be what you are thinking
of), I quote "an identifiable natural person is one who can be
identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an
online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identity of
that natural person;"
> Yes, if you know who they are you can see what they did, but you
> cannot see from what they did who they are. At best you can guess, but
> it only works if you have additional information that the person (or
> someone else) would have to provide you with. What we have according
> to these definitions is "pseudonymisation" (because OSMF has the
> sign-up e-mail address associated with the user number, and is
> therefor in a position to make personal data from the contributions).
>
> If someone tries to reverse the pseudonymisation of our contributor's
> data and metadata, it would be this person to be in breach of the law.

Pseudonymisation is one of the data protection safe guards proposed by
the GDPR, use of it does not make the data itself less "Personal Data"
see Recital 26 /"Personal data which have undergone
//pseudonymisation//, which could be attributed to a natural person by
the use of additional information should be considered to be information
on an identifiable natural person". /, it just may make some processing
possible of such data that otherwise would not be permissible.

>
> An exception might occur in very rare cases in areas where the
> contributor is the only person being there within a big distance, i.e.
> extremely remote areas, and probably not in the European Union.

Again, see above, we know first hand how many of our contributors can be
identified alone from display name, location of initial edits, other
hints and so on. Not quite sure why you are in denial about this as you
were present when that took place.

Simon

>
> For reference,
>
> General Data Protection Regulation
> https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en
>
>
> Cheers,
> Martin



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

Re: [OSM-dev] Working with OSM data with less or no metadata

[Simon Poole]

Am 16.02.2018 um 13:09 schrieb Martin Koppenhoefer:
> 2018-02-16 0:04 GMT+01:00 Paul Norman  >:
>
> On 2/14/2018 8:17 AM, Roland Olbricht wrote:
>
>
> - How about simply asking the users for consent? We could then
> -- make a clear-cut last complete history dump before the date
> -- start with a planet dump without history before that date
> afterwards that then accumulates history only from users that
> have given consent
>
>
> Consent is revocable. If we didn't have to deal with people
> revoking consent and account deletion requests, it would all be
> much easier.
>
>
>
>
> We are asking for "a worldwide, royalty-free, non-exclusive,
> perpetual, irrevocable licence to do any act that is restricted by
> copyright, database right or any related right over anything within
> the Contents, whether in the original medium or any other." Do you
> have reason to believe the "irrevocable" part is invalid?
No, because you can give an irrevocable licence in intellectual property
matters (that is a rough generalisation, I know, as certain
jurisdictions actually limit that).
>
> "Contents" means "data and/or any other content (collectively,
> “Contents”)" [which the user contributes] "to the geo-database of the
> OpenStreetMap project"
> https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms
>
> Account deletions are another issue, but don't seem complicated:
> remove the human readable account alias and e-mail forwarding and
> prevent it from editing.
>
The intellectual property rights (I re-quote: "that is restricted by
copyright, database right or any related right") have nothing to do with
the subject at hand, the data privacy rights of the individual data
subject. As a consequence the contributor terms have no bearing, in any
form, at all, even in an alternative universe, on the matter.

If you look at our recommendation document you will note that we believe
that we currently do not have consent as defined by the GDPR for the
processing we do. As a consequence we will likely recommend  asking for
explicit consent somewhere in the sign up process (from a content pov
this already exists in the privacy policy but it needs to be re-jigged
to work as part of the terms of use that will have to be explicitly
agreed to for account creation).

However having valid consent for current processing does not remove the
issue that Paul has pointed out (again) that consent can be redrawn and
that such a withdrawal applies retroactively. The main cause why we one
way or the other should change what data we distribute to the general
public.

Simon

> Cheers,
> Martin
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Working with OSM data with less or no metadata

[Simon Poole]

The LWG won't be making any "decisions" we will be making
recommendations to the board, which may or may not take action on them.

Generally I would prefer if we could simply have two versions of
everything, one with metadata for authenticated users/consumers one
without. This likely will not be feasible for everything, but at least
for the important stuff.


Am 14.02.2018 um 17:17 schrieb Roland Olbricht:
> Hi,
>
>> - timestamps however cannot only potentially be used in lieu of
>> changeset ids to group contributions, the information itself is
>> problematic because it allows to profile contributions over time
>
> Timestamps are necessary to correctly figure out which nodes have
> belonged to a certain version of a way, and similarly for ways and
> nodes belonging to relations.
>
> More generally:
>
> - What is planned with regard to minute diffs? Stripping extra
> information will inevitably break tools like Achavi
>
> - Tools will need substantial time (I would estimate 3-6 months for
> Overpass API) to adapt in a meaningful way. What is the schedule of
> the LWG to take decisions?
>
The deadline is more or less clear for things that we consider really
touchy, they need to be fixed by the end of May.

Wrt Overpass API, there is no reason why you couldn't consume diffs as
up to now, as long as the output is sanitized (regardless of what the
OSMF says and does, the GDPR doesn't go away for you, so you need to
consider your options in any case).

> - How about simply asking the users for consent? We could then
> -- make a clear-cut last complete history dump before the date
> -- start with a planet dump without history before that date
> afterwards that then accumulates history only from users that have
> given consent
>

The problem is that that doesn't solve anything as, recently confirmed
by the EU, consent is only considered freely given and valid, if it can
be withdrawn, and from a practical pov that essentially forces two
distribution streams on different terms (one that can be used without
any privacy related restrictions and one with with all the trouble).

> Personally, I would prefer a solution as easy as dropping usernames
> and uids but retaining changeset ids, timestamps and the geometry/tag
> data.
> That way we display goodwill, but do not cripple the tools that have
> proven useful or crucial to run the project.

Unluckily what I would prefer is not the question :-/.

Simon

>
> Please note that in the context of an API without user interface, it
> is a substantial challenge in itself to have any form of (OAuth or so)
> authentification.
>
> Cheers,
> Roland
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] Working with OSM data with less or no metadata

[Simon Poole]

General comments:

- we are just considering removing metadata from what is publicly
available outside of the OSM community, the current thinking is that it
can remain available to authenticated users

- while there might be a tiny bit of leakage from providing version
numbers we haven't considered them to be a large concern, and a good
argument can be made while they need to be public (see below)

- timestamps however cannot only potentially be used in lieu of
changeset ids to group contributions, the information itself is
problematic because it allows to profile contributions over time

Neither uid/display name and timestamp of an existing object version are
required to create a modified version for upload to the API, the version
number however is.

Simon


Am 14.02.2018 um 10:30 schrieb Michael Reichert:
> Hi,
>
> people are talking about potential changes to the amount of (personal)
> data distributed by OSM, in the light of new data protection laws
> becoming effective in the EU this May. There haven't been any official
> statements by the OSMF but discussions are going on in the LWG [1].
>
> Even though it is still unclear what the concrete steps will be, I have
> done some experiments. How well do our existing tools behave if you feed
> them with OSM data that has less metadata than usual, or no metadata at
> all? I have set up a test suite which tests Osmium-Tool (which uses the
> Libosmium library; master branch), Osmosis 0.44.1 and Osmconvert 0.6.
>
> The test suite is availabe at
> https://github.com/geofabrik/metadata-test/
> and consists of a Bash script. You need to have osmium, osmosis and
> osmconvert in your path (or you have to modify the script a bit). The
> test suite comes with its own hand crafted test data which will be first
> converted to PBF by Osmium. Afterwards all three tools will prove
> themselves in the following challenges:
>
> - converting XML to PBF
> - converting PBF to XML
> - converting XML to XML
> - applying a diff
> - deriving changes between two OSM files
>
> All challenges are run four times, one iteration with full metadata, one
> with timestamp and version fields, one with version field only and one
> without any metadata. Some PBF challenges will also have two variants –
> one with DenseNodes and one without.
>
> The results are files located in the output/ directory. You have to
> inspect them manually, I have not written a tool to parse them and
> output how many tests failed.
>
> *Results*
> I compiled the results into a spreadsheet. You can download it at
> https://github.com/geofabrik/metadata-test/raw/master/table.ods
>
> To sum them up:
> - Osmium is the only programme which passes all format conversion tests.
>
> - Osmosis cannot read any XML (OSM and OSC) files without timestamp and
> version fields.
>
> - Osmosis and Osmconvert [2] treat all metadata fields in the DenseInfo
> message of the PBF format as mandatory. However, the format
> specification doesn't declare these fields as mandatory. Therefore, they
> write default values into PBF files if the input lacks these fields:
> version="-1" timestamp="1969-12-31T23:59:59Z" changeset="-1" (Osmosis [3]),
> timestamp="1970-01-01T00:00:01Z" changeset="1" version="1" (Osmconvert)
> This partially applies to the XML output of Osmosis, too.
>
> - Deriving a diff file of the changes between two OSM files only works
> if both files have the same amount of metadata. If one file contains
> less or more metadata, all objects will appear in the diff file with
> their new metadata and bloat it up. The question is whether this is the
> desired behaviour (i.e. the ability to clean a file from metadata using
> large diffs) or if this behaviour is not desired and the tools
> generating diffs should compare the tags, location and members of
> objects which have the same ID but different metadata.
>
> - Some tools have bugs which lead to wrong diffs (e.g. missing
> modifications) if some metadata fields are missing.
>
> Best regards
>
> Michael
>
>
> [1]
> https://wiki.osmfoundation.org/wiki/Working_Group_Minutes#Licensing_Working_Group
> [2] Osmium also had this bug. But it was fixed on the master branch a
> few days ago.
> [3] Osmium cannot parse negative version numbers and throws an exception.
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] using leaflet and OSM for commercial use

[Simon Poole]

http://lmgtfy.com/?q=openstreetmap+licence


Am 25.11.2017 um 21:15 schrieb Dave Lae:
> Hello
> Could you please tell me if it is allowed to use OpenStreetMap on a
> website, use Leaflet to place some markers on it and get profit on the
> website? Do you allow it, yes or no or under what
> circumstances/requirements/obligations?
>
> Best regards
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] XAPI

[Simon Poole]

I can probably do it for you, I need to know the file/data format you
would like and projection (I assume you want points and that the output
should be de-duplicated in some form). All tags? Or just some specific one?

Simon


Am 07.08.2017 um 19:52 schrieb Fredy Yanez:
> Thanks! 
>
> I understand that i might not get 100% coverage. That is okay. Any
> data that I can get is useful.
>
> How would one go about contacting a friendly operator of a osm2pgsql
> server? 
>
>
> Fredy
>
>
> *From: * Simon Poole 
> *To: * 
> *Sent: * 8/7/2017 12:08 PM
> *Subject: * Re: [OSM-dev] XAPI
>
> There are multiple reasons why this is not going to work, not the
> least that there have been no public native XAPI servers available
> for a very long time.
>
> See http://wiki.openstreetmap.org/wiki/Xapi
>
> But in any case extracting anything for the whole world from any
> API is not a good idea, I would suggest downloading a planet dump
> and filtering the objects out of it, or asking a friendly operator
> of a osm2pgsql server with the whole planet imported to generate a
> list of schools for you.
>
> The other thing to take in to account, that while we undoubtedly
> have a lot of schools in OSM and in some areas will have 100%
> coverage this is definitely not universal.
>
> Simon
>
>
> Am 07.08.2017 um 17:43 schrieb Fredy Yanez:
>> Good afternoon, 
>>
>>
>> I'm working for a no profit and our goal is to measure internet
>> connectivity for every school in the world. It would be very
>> beneficial is we had access to every school within the database.
>> To do this I've been trying to use XAPI and I'm having a few errors.
>>
>>
>> For example when I try to use XAPI URLs:
>>  wget
>> 
>> --timeout=0http://www.informationfreeway.org/api/0.6/node[amenity=schools]-O
>> data.osm
>> I get this link as a response: 
>>
>> http://www.informationfreeway.org/noapi.html
>>
>>
>> and in data.osm I get :
>>
>> /
>>
>> 
>>
>> No API
>>
>>
>> 
>>
>>
>> I was wondering what I'm doing wrong?
>>
>> My guess is that I'm not authenticating or something along those
>> lines.
>>
>>
>> What is the best way to solve this problem ?
>>
>>
>> Thanks !
>>
>> Fredy
>>
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/dev
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>



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

Re: [OSM-dev] XAPI

[Simon Poole]

There are multiple reasons why this is not going to work, not the least
that there have been no public native XAPI servers available for a very
long time.

See http://wiki.openstreetmap.org/wiki/Xapi

But in any case extracting anything for the whole world from any API is
not a good idea, I would suggest downloading a planet dump and filtering
the objects out of it, or asking a friendly operator of a osm2pgsql
server with the whole planet imported to generate a list of schools for you.

The other thing to take in to account, that while we undoubtedly have a
lot of schools in OSM and in some areas will have 100% coverage this is
definitely not universal.

Simon


Am 07.08.2017 um 17:43 schrieb Fredy Yanez:
> Good afternoon, 
>
>
> I'm working for a no profit and our goal is to measure internet
> connectivity for every school in the world. It would be very
> beneficial is we had access to every school within the database. To do
> this I've been trying to use XAPI and I'm having a few errors.
>
>
> For example when I try to use XAPI URLs:
>  wget
> --timeout=0http://www.informationfreeway.org/api/0.6/node[amenity=schools]-O
> data.osm
> I get this link as a response: 
>
> http://www.informationfreeway.org/noapi.html
>
>
> and in data.osm I get :
>
> /
>
> 
>
> No API
>
>
> 
>
>
> I was wondering what I'm doing wrong?
>
> My guess is that I'm not authenticating or something along those lines.
>
>
> What is the best way to solve this problem ?
>
>
> Thanks !
>
> Fredy
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] RIP Potlatch ?

[Simon Poole]

Note that 2020 is a good 2.5 years away, a long enough time to repackage
P2 for desktop use and or perhaps start on yet another in-browser editor.

Simon

Am 25.07.2017 um 21:14 schrieb ika-chan! (OpenStreetMap):
> Source: http://www.bbc.co.uk/news/technology-40716304
>
> So I guess that’s it for Potlatch? I still use it when I wanted to edit the 
> woodland without turning it into a multipolygon while splitting the ways for 
> retracing, and where I wanted to make a gap between two connected polygons to 
> add, say, a farmyard.
>
> — ika-chan!
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

[OSM-dev] Reminder: OpenStreetMap Organisation on transifex

[Simon Poole]

Just a reminder to all:

There is an OpenStreetMap organisation entity on transifex (which tends
to be the most popular i18n platform in OSM space) that you can move
your project to. Previously this required re-inviting all translators,
but this in no longer the case making the whole thing a lot easier. If
you move your project you retain control and the only real downside is
that you need to change any links you have pointing to the resp.
transifex projects.

Why would you want to do this?

Besides some soft factors (more exposure to a larger group of
translators and so on), projects in the same organisation can share
translations, making translation both faster and more consistent.

Caveat:

From a licence pov your translations should be licensed CC0 or similar,
given that they will potentially be used by projects with a number of
different, but always open, licences (given that the translation sharing
is at the individual expression level typically, you could argue that
copyright does not apply, but lets not venture in to that kind of
argument) .

Simon




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

Re: [OSM-dev] Javascript library for the editing-API (not overpass)

[Simon Poole]

Am 24.04.2017 um 18:36 schrieb Viet Nguyen:
> Thanks Martin and Simon.
>
> It was my intention to reach out for suggestions before writing
> anything to OSM db (and of course not without some testing with the
> dev instance).
>
> Simon, can you please clarify what you meant by 'there is no other
> data there'?  Are you referring to the risk of creating empty relations?
>
I was referring to crag and other relevant data already being present in
OSM (note that your proposed app will lead to such situations even if
you believe that it currently can't happen).

Simon

> Before writing to OSM my app would have to convert Geojson polygons
> (its native format) to OSM list of nodes similar to areas in iD.
>
>  
>
>
>
> On Mon, Apr 24, 2017 at 1:29 AM, Simon Poole  <mailto:si...@poole.ch>> wrote:
>
> Martin has already pointed to the iD repo. But some further
> comments from my side: simply creating objects and writing them to
> the OSM DB is fairly easy, however there is an unspoken assumption
> in your concept: that there is no other data there. In reality
> that will not be universally true and will add complications that
> you likely don't want to deal with (or if you ignore them you will
> not want to deal with being publicly roasted because your app
> starts breaking things).
>
> I would really suggest building on existing code except if you
> want to write the equivalent of a full blown editor all on your
> own (which is a couple of man years of work).
>
> Simon
>
>
> Am 23.04.2017 um 18:46 schrieb Viet Nguyen:
>> Hello,
>>
>> I'm a new subscriber.  I have looked on Github, iD repo, and npm
>> but haven't found a Javascript that can be used with the editing
>> API.  Before rolling my own library (JS is not my strong suit) I
>> thought I should check with members of the dev list.
>>
>> TLDR;
>> I want to experiment with creating polygons describing rock
>> climbing areas and submit them to OSM. 
>>
>> https://lists.openstreetmap.org/pipermail/talk/2017-April/077879.html
>> <https://lists.openstreetmap.org/pipermail/talk/2017-April/077879.html>
>>
>> Viet
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/dev
>> <https://lists.openstreetmap.org/listinfo/dev>
>


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

Re: [OSM-dev] Javascript library for the editing-API (not overpass)

[Simon Poole]

Martin has already pointed to the iD repo. But some further comments
from my side: simply creating objects and writing them to the OSM DB is
fairly easy, however there is an unspoken assumption in your concept:
that there is no other data there. In reality that will not be
universally true and will add complications that you likely don't want
to deal with (or if you ignore them you will not want to deal with being
publicly roasted because your app starts breaking things).

I would really suggest building on existing code except if you want to
write the equivalent of a full blown editor all on your own (which is a
couple of man years of work).

Simon


Am 23.04.2017 um 18:46 schrieb Viet Nguyen:
> Hello,
>
> I'm a new subscriber.  I have looked on Github, iD repo, and npm but
> haven't found a Javascript that can be used with the editing API. 
> Before rolling my own library (JS is not my strong suit) I thought I
> should check with members of the dev list.
>
> TLDR;
> I want to experiment with creating polygons describing rock climbing
> areas and submit them to OSM. 
>
> https://lists.openstreetmap.org/pipermail/talk/2017-April/077879.html
>
> Viet
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Legal question about attribution text on smartphone

[Simon Poole]

I hope you realize just how patently silly that post was.

But just in case you don't: you get legal advice from the counsel that
you have engaged (and typically they will want money for that), you do
not get it from a public developers mailing list (it is however the
right place to get personal opinions on app design). Not only are there
only a small number of people qualified to do so on the list, there are
many legal (which you should know as a German company), liability and
economic reasons why you will not get anything useful here.

You need to sit down with your counsel and go through your options and
the associated risks and then decide what works best. Dealing with
customers using your SDK and getting them to attribute the data sources
correctly is going to be pain, just ask mapbox.

Simon

Am 23.04.2017 um 14:49 schrieb Stadin, Benjamin:
>
> I need a legal advice, not a personal opinion about app design. That
> we need to show our own logo –we didn’t show it before but showed the
> OSM attribution text- has a solid legal background, which I won’t go
> into detail in a public mailing list. That we want to show only one
> logo on smartphones really has its reason also. We can show both on
> the iPad and Android tablets. And in our own apps, where we can
> control content and UI, we credit OSM at multiple places (legal or
> about page, as well as on the map view itself).
>
>  
>
> Cheers
>
> Ben
>
>  
>
>  
>
> *Von: *Simon Poole 
> *Datum: *Sonntag, 23. April 2017 um 13:41
> *An: *"dev@openstreetmap.org" 
> *Betreff: *Re: [OSM-dev] Legal question about attribution text on
> smartphone
>
>  
>
> IMHO mobile devs tend to substantially exaggerate the screen real
> estate scarcity. Two to three sources as text lines is clearly doable,
> and you don't really need to have separate links on the main screen
> itself, just show a common attribution screen.
>
> And: -you- control how much you want to show your logo, it is -not- a
> third party legal requirement, no reason you can't simply live with
> some text if you believe there is not enough space.
>
> Simon
>
>  
>
> Am 23.04.2017 um 00:26 schrieb Stadin, Benjamin:
>
> It’s not our app, but this is an (indoor) map SDK which can be
> integrated into other native iOS and Android apps. A list
> (UIActionSheet on iOS) appears when our logo is tapped, showing
> multiple links (including a link to
> www.openstreetmap.org/copyright
> <http://www.openstreetmap.org/copyright>). Having our logo visible
> is a legal requirement also, and it wouldn’t be convenient to
> place the list with multiple legal links not associated to OSM
> behind the OSM attribution logo or text.
>
>  
>
> If we need to show two logos it would waste space for navigation
> controls and building / floor selection UI elements.
>
>  
>
> Since the map view will be used in other apps, we cannot control
> what is shown on the splash screen. We can place it there for our
> own apps, and ask customers of our SDK to place it there. But from
> experience this is often forgotten, and I’d rather prefer a
> permanent solution and give credit to OSM one way or another on
> the map view.
>
>  
>
> Cheers
>
> Ben
>
>  
>
>  
>
> *Von: *Martin Koppenhoefer 
> <mailto:dieterdre...@gmail.com>
> *Datum: *Freitag, 21. April 2017 um 12:49
> *An: *Rory McCann  <mailto:r...@technomancy.org>
> *Cc: *"dev@openstreetmap.org" <mailto:dev@openstreetmap.org>
>  <mailto:dev@openstreetmap.org>,
> "legal-t...@openstreetmap.org"
> <mailto:legal-t...@openstreetmap.org>
>  <mailto:legal-t...@openstreetmap.org>
> *Betreff: *Re: [OSM-dev] Legal question about attribution text on
> smartphone
>
>  
>
>
>
> sent from a phone
>
>
> On 21. Apr 2017, at 12:10, Rory McCann  <mailto:r...@technomancy.org>> wrote:
>
> So I dunno? Maybe? There could be ways around it if you don't
> want to include it on every map page. Does your app have a
> loading/spash screen? Including an attribution there, which is
> shown every time the app is started might meet the requirements.
>
>  
>
>  
>
> have you seen this page?
>
> https://wiki.openstreetmap.org/wiki/Legal_FAQ
>
>  
>
> generally, if there is enough space for your logo, there should
> also be for osm (on pages showing maps). If there's space for just
> one attribution, why not use it to attribute osm? The user will
&

Re: [OSM-dev] Legal question about attribution text on smartphone

[Simon Poole]

IMHO mobile devs tend to substantially exaggerate the screen real estate
scarcity. Two to three sources as text lines is clearly doable, and you
don't really need to have separate links on the main screen itself, just
show a common attribution screen.

And: -you- control how much you want to show your logo, it is -not- a
third party legal requirement, no reason you can't simply live with some
text if you believe there is not enough space.

Simon


Am 23.04.2017 um 00:26 schrieb Stadin, Benjamin:
>
> It’s not our app, but this is an (indoor) map SDK which can be
> integrated into other native iOS and Android apps. A list
> (UIActionSheet on iOS) appears when our logo is tapped, showing
> multiple links (including a link to www.openstreetmap.org/copyright
> ). Having our logo visible is
> a legal requirement also, and it wouldn’t be convenient to place the
> list with multiple legal links not associated to OSM behind the OSM
> attribution logo or text.
>
>  
>
> If we need to show two logos it would waste space for navigation
> controls and building / floor selection UI elements.
>
>  
>
> Since the map view will be used in other apps, we cannot control what
> is shown on the splash screen. We can place it there for our own apps,
> and ask customers of our SDK to place it there. But from experience
> this is often forgotten, and I’d rather prefer a permanent solution
> and give credit to OSM one way or another on the map view.
>
>  
>
> Cheers
>
> Ben
>
>  
>
>  
>
> *Von: *Martin Koppenhoefer 
> *Datum: *Freitag, 21. April 2017 um 12:49
> *An: *Rory McCann 
> *Cc: *"dev@openstreetmap.org" ,
> "legal-t...@openstreetmap.org" 
> *Betreff: *Re: [OSM-dev] Legal question about attribution text on
> smartphone
>
>  
>
>
>
> sent from a phone
>
>
> On 21. Apr 2017, at 12:10, Rory McCann  > wrote:
>
> So I dunno? Maybe? There could be ways around it if you don't want
> to include it on every map page. Does your app have a
> loading/spash screen? Including an attribution there, which is
> shown every time the app is started might meet the requirements.
>
>  
>
>  
>
> have you seen this page?
>
> https://wiki.openstreetmap.org/wiki/Legal_FAQ
>
>  
>
> generally, if there is enough space for your logo, there should also
> be for osm (on pages showing maps). If there's space for just one
> attribution, why not use it to attribute osm? The user will more
> likely be aware who you are (as he's using your app) than he will be
> that your map data comes from osm, so prioritizing OSM attribution
> seems to make sense 
>
>  
>
>  
>
> cheers,
>
> Martin 
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Programatic reconstruction of postal code areas

[Simon Poole]

Speaking on the Swiss situation, there is an open access postal area
dataset available on a wonky licence, depending on what you want to use
it form it may be OK. See
https://opendata.swiss/en/dataset/amtliches-ortschaftenverzeichnis-mit-postleitzahl-und-perimeter1

Originally at least it was generated by examining the postal delivery
routes, now days it lives a senseless and expensive life of its own.
Note that it is updated on a monthly base and tends to have a large
number of changes every time.

As to address data in OSM: there is no real agreement if we are tagging
real postal addresses including postal cities or not, postal cities tend
to be difficult to survey and not really accessible for non-locals, so
tend to end with a mix of admin entities and postal whatevers in addr:city.

Simon



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

Re: [OSM-dev] Unified Preset Management System GSOC 2017

[Simon Poole]

Peter has already touch on most of the salient points.

I think that it is important to understand that all of the ideas for
projects are just that. Some are are sketched bit more detailed than
others, but it is still up to the student to build a credible proposal
around them, or create one completely on their own.

The project idea in this case highlights an issue that we undeniably
have in OSM, and one for which earlier attempts to resolve have failed.
Please don't decide on a specific implementation before the rest of the
bases have been covered.

Simon

Am 01.03.2017 um 20:55 schrieb Rohit Lodha:
> Hello,
> I am Rohit, a sophomore pursuing B.E Computer Science at Birla
> Institute of Technology and Science,Pilani. I have been developing
> websites and managing them for the last one year for my college and a
> start-up that I had worked with. I have a huge interest in Python and
> Django and have build almost all the websites using them.
>
> *I want to contribute to Open Street Map Organisation by working on
> Unified Preset Management Systemduring the summer. * I have worked on
> many websites before. You can have a look at one of the website made
> and managed by me for my college here - http://ssms-pilani.org/
>
> Can you please tell me how to proceed or any task you expect me to
> carry out to be a part of the community ?
>
> -Rohit Lodha
> My Github profile: https://github.com/rtgdk
> Gitlab profile : https://gitlab.com/rtgdk
>
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] tag implication database/library

[Simon Poole]

Interesting, I assume you are both aware of:

http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

which covers just part of the problem space. For example to do it
properly you need to normalize vehicle types, add rules for
standing/parked vehicles and so on.

Simon


Am 24.11.2016 um 17:54 schrieb Michael Maier:
> On 17/11/16 11:51, Per Eric Rosén wrote:
>> Hi!
>>
>> I have been making a few maps and applications using OSM data, mostly
>> stored in postgis. In all cases, I have had to make custom carto rules /
>> database post-processing / application rules to compensate for multiple
>> ways of expressing the same information in OSM. Also, in some cases,
>> for taking care of which tag implies which information.
>>
>> Is there some way of doing this just once; for example with some
>> parseable implication database, and library? There is some "implies" on
>> the wiki; but it's not completely chine-readable in a reliable way.
>>
>> Such a database would probably also need being optionally keyed on
>> country, "highway=cycleway" may imply different rules in different
>> countries for example.
>>
>> Would such a tool/database be useful, if not existing already?
> Definitely, I would have needed such a tool a few times already.
>
>> I see two somewhat different usage cases, and I don't know if the same
>> tool/database should be used for both:
>>
>> 1. normalizing a database before usage, for example changing
>>"highway=ford" to "ford=yes" and moving to modern lifecycle tags
>>
>>(it could be argued that this shoud be done on the main OSM database
>> by a bot, but data consumers could probably have larger or more
>> specific needs of normalization compared to what can be agreed to do
>> by changing the master OSM data)
>>
>> 2. getting specific implications without writing it to a database, for
>>example highway=cycleway implies bicycle=yes, foot=yes in country X
> I would suggest to start a project to use Wikidata for that:
> • create a Wikidata object for every key and for every key=value pair of
> interest.
> • Link them together with
>   · subclass_of (P279¹) for key=value to key
>   · when two tags are meant for the same objects, set P460²
>   · for “implies” I haven't found a property yet, is that possible?
> • replace the currently used P1282³ with a new property linking to the
> new Wikidata entries for tags
>
> [1] https://www.wikidata.org/wiki/Property:P279
> [2] https://www.wikidata.org/wiki/Property:P460
> [3] https://www.wikidata.org/wiki/Property:P1282
>
> Who would be willing to join the effort?
>
> Thanks,
> Michael
>
>> best regards
>> Per Eric Rosén
>> -- 
>> ^): Per Eric Rosén http://rosnix.net/~per/
>> /   p...@rosnix.net GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

[OSM-dev] Use policies update

[Simon Poole]

All three OSM usage policies (
https://wiki.openstreetmap.org/wiki/Acceptable_Use_Policy ) have been
updated to include a section pointing out that use of these services is
subject to our Privacy Policy
(http://wiki.osmfoundation.org/wiki/Privacy_Policy ) see for example
https://wiki.openstreetmap.org/wiki/Nominatim_usage_policy#Privacy While
use of the services was naturally already subject to the policy, adding
the section makes it easier for service users to find the document.

Further I've added an recommendation to the "Tile usage policy" (
https://wiki.openstreetmap.org/wiki/Tile_usage_policy ) to include a
suitable link to the "fixthemap" page.

Both changes do not conflict with the current discussion on how the
usage policies should evolve
https://github.com/openstreetmap/operations/issues/113 but that
discussion prompted me to get the above changes off my todo list at last.

Simon

-- 
OpenStreetMap Foundation
132 Maney Hill Road
Sutton Coldfield
B72 1JU
United Kingdom
A company limited by guarantee, registered in England and Wales.
Registration No. 05912761.





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

Re: [OSM-dev] Tile usage without proper identification

[Simon Poole]

Am 12.08.2016 um 20:27 schrieb Matthijs Melissen:
> 
> I would tend to disagree.
>
> Our Articles of Association state:
>
> | 3. The Foundation is established for the purposes listed below:
> |
> | (1) encouraging the growth, development and distribution of free geospatial
> | data; and
> | (2) providing geospatial data for anybody to use and share.
>
> To me this would include the distribution of geospational data in
> compiled form, i.e. as a map.

The OSMF AoA do not prescribe any specific way how the purposes should
be achieved and traditionally the project has left distribution to end
users to third parties, commercial and others (see
https://www.openstreetmap.org/user/SimonPoole/diary/34883) .

>
> I think it would be great if we had the resources to provide free maps
> to anybody, including commercial companies. I realize there are
> practical considerations that make this infeasible at the moment, but
> I think it would be a nice target to aim for. The easier and cheaper
> to use Openstreetmap-data, the more people will use it, which will
> hopefully in turn lead to more contributors and better data.

The WMF on the other hand has historically had tight control over its
distribution channels and built its whole business model around that.
Which is one of the reasons that they have felt a lot of pressure
recently because they have been losing significant parts of that
control. The OSM model removes all that stress from the community and
has proven quite effective none the less.

>
> I would also like to point out that there might be a conflict of
> interest here between commercial operators of OpenStreetMap services,
> and the rest of the community.
Well, despite slightly confused recent blog posts from some of the
commercial players claiming the opposite, the OSM community has
consistently elected a dominating majority of such operators (commercial
and others) to the OSMF board for many many years with typically only
one to two token representatives of the mapping community. As a result I
have to assume that the community is happy with the OSMF strategy as it is.

Simon

PS: this discussion would seem to be rather off topic on the dev mailing
list.



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

Re: [OSM-dev] Simple app for "making contributions" (not to display maps)

[Simon Poole]

Am 29.06.2016 um 14:33 schrieb Rory McCann:
> Hi,
>
> One could claim that Maps.me is an attempt to make a simple to use
> smartphone app for non-technical people to contribute data to OSM. It
> doesn't require aerial imagery, nor always-on internet access.
>
It is weird that everybody is falling for the same trap of completely
forgetting (or is it just mail.ru marketing?) all the apps and programs
that have come and gone that have promised simple contributing ...
starting off with the Mapzen POI collector. Fact is none of them have
really delivered on the promise and essentially all have cut corners in
one way or the other.

If there is nothing mapped in an area having a (pre-cached) imagery
layer is a plus, not a minus.



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

Re: [OSM-dev] Simple app for "making contributions" (not to display maps)

[Simon Poole]

Bjoern

In general I'm not convinced that raw GPS tracks are of a lot of use
without additional information in areas that might not have a well
established road network, that essentially makes the whole simple part
already more complex. Historically, before the advent of high resolution
imagery being available for tracing, it was not uncommon to have phantom
ways in OSM, where a well-meaning soul had turned a random GPS track in
to a road where there was none (for example somebody short-cutting
across a meadow).


Am 29.06.2016 um 14:04 schrieb Bjoern Hassler:
> Hi all,
>
> first post to the list - hope this is of interest.
>
> The background to my question is working is areas where map coverage
> is poor (e.g. parts of Africa). Sometimes only low-res satellite/bing
> imagery is available, sometimes obscured by clouds. In some low
> populated areas a GPS trace could be useful to map out roads
> connecting settlements (despite inaccuracies of GPS).
>
> There are many great OSM apps out there, including apps for recording
> traces (e.g. OSM tracker, etc). However, unless I've missed it, I
> would say that none of those apps is suitable for the "non-technical"
> user. Indeed, we've tried using various such apps, and it's been
> difficult in terms of usability.
>

Who is "we" in this context?

Simon

> Is there interest in (or is anybody working on) creating an very
> simple-to-use app that allows "non-technical" users to contribute OSM
> information? E.g. a large red button for recording a trace with
> automatic upload (optimised for poorly internet connected
> environments, e.g. wait for wifi, upload in chunks etc; information
> submitted with GPS accuracy information).
>
> (There are of course issues with GPS traces, so perhaps automated
> capture of GPS traces is not that useful.)
>
> Many thanks!
> Bjoern
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Using API 0.6 to create a new node

[Simon Poole]

And please (please please please) -do- check existing data before you
upload.

Am 14.06.2016 um 18:31 schrieb Ian Dees:
> Also, don't forget to use the dev server to do your testing so you
> don't accidentally create bad data in the real database. The URL
> is http://master.apis.dev.openstreetmap.org/.
>
> On Tue, Jun 14, 2016 at 12:13 PM Bryan Housel  > wrote:
>
> You can’t just pass “0” as the changeset id.
>
> Your app will need to create a changeset first with :
> 
> http://wiki.openstreetmap.org/wiki/API_v0.6#Create:_PUT_.2Fapi.2F0.6.2Fchangeset.2Fcreate
>
> This diagram talks a bit about the flow of how to create a
> changeset, issue updates against it, then close the changeset:
> 
> http://wiki.openstreetmap.org/wiki/File:OSM_API0.6_Changeset_successful_creation_V0.1.png
>
>
>
>
>> On Jun 14, 2016, at 11:41 AM, toni hernández > > wrote:
>>
>> Hi everyone,
>>
>> I am trying to display OSM data into my web map as well as other
>> custom layers.
>> One of the goals of my web application is to upload data from my
>> application to the osm database.  I have been reading this
>> http://wiki.openstreetmap.org/wiki/API_v0.6#Elements but still I
>> do not understand how a PUT request functions. I have so much to
>> learn
>>
>> After authentificating with osmauth.js I try this code without
>> any success. I get a 401 error.
>>
>> var xml_string = ' > version="0.6" generator="MyOpenstreetmapApp">> lat="41.983910" lon="2.816094">> v="supermarket"/>';
>>
>> ajaxurl= "http://www.openstreetmap.org/api/0.6/node/create";
>> ;
>>
>> $.ajax({
>> url: ajaxurl,
>> data: xml_string,
>> type: 'PUT',
>> contentType: "text/xml",
>> dataType: "text",
>> success : function (resp){console.debug(resp)},
>> error : function (xhr, ajaxOptions, thrownError){ 
>> console.log(xhr.status); 
>> console.log(thrownError);
>> }
>> });   
>>
>> Do I need to include oauth_secret and oauth_consumer_key from the
>> authentification proccess in the ajax request?
>>
>> Any help will be really apreciated.
>> Thanks
>> -- 
>> *Toni Hernández Vallès*
>> Servei de Sistemes d'Informació Geogràfica i Teledetecció
>> -
>> Universitat de Girona
>> *SIGTE*
>> -
>> Pl. Ferrater Mora 1
>> 17071 Girona
>> Tel +34 972 418 039 (7026 intern)
>> t...@sigte.udg.edu 
>>
>> http://www.sigte.udg.edu 
>> Twitter http://twitter.com/SIGTE_UDG
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/dev
>
> ___
> dev mailing list
> dev@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/dev
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] editing OSM-files with Java

[Simon Poole]

There is a longish thread somewhere on the German forum on the topic (no
idea if JAVA was involved) where somebody did exactly that (create and
prune "virtual ways" over areas in a prototype implementation). it would
be 1-2 years back so might need some hunting to find.

Simon


Am 07.06.2016 um 15:29 schrieb Jakob Miksch:
> Dear list members,
>
> I want to edit OSM-files with Java.
>
> I would like to add virtual ways to highway areas in order to allow a
> routing engine to compute routes through such areas. Example:
> https://www.dropbox.com/s/ptt1db77wnxv5kr/example.png?dl=0
>
> So, basically many new nodes and ways will be added and the boundary
> of the area will receive more nodes.
>
> For input and output both the ".osm" and ".osm.pbf" format should be
> supported.
>
> Moreover the solution should also work for big datasets (country,
> continent or even planet).
> Since just a small share of all features (highway areas make up a
> share of ~1% of all highway features) would be changed, it would
> probably make sense just to edit the OSM-file. Writing the whole
> OSM-data to another file might take more time than necessary.
>
> I already found the "osm4j" library which sounds quite promising
> (http://www.topobyte.de/projects/osm4j/).
>
> Do you think this plan sounds feasible, do you have any suggestions
> for the implementation?
>
> Best wishes,
> Jakob
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

[Simon Poole]

It is probably a good idea to have a look at

http://www.asklater.com/matt/blog/2015/11/18/the-road-to-api-07/

of which cgimap and developing it further is a key piece.

Simon 


Am 04.06.2016 um 18:34 schrieb Stadin, Benjamin:
> Hi Bryan,
>
> thank you for these pointers.
>
> A somehwat unrelated question: The FAQ mentions cgimap. Is this
> performance optimized map API implementation still relevant and is it
> still in use? Will a production system benefit from this
> significantly, when it has to deal with lots of requests?
>
> Thanks
> Ben
> 
> *Von:* Bryan Housel 
> *Gesendet:* Samstag, 4. Juni 2016 18:03:19
> *An:* Stadin, Benjamin
> *Cc:* osm-dev
> *Betreff:* Re: [OSM-dev] OSM + iD + Nominatim Setup instructions
>  
> Hi Ben,
>
> iD’s connection to OSM is in `connection.js`:
> https://github.com/openstreetmap/iD/blob/a8ac9faad8a597d81813d8effd5cc5c1a1a0a668/js/id/core/connection.js#L8-L19
>
> iD’s connection to Nominatim is in the `nominatim.js` service:
> https://github.com/openstreetmap/iD/blob/master/js/id/services/nominatim.js#L3
>
> See also from our FAQ:
> https://github.com/openstreetmap/iD/blob/master/FAQ.md#can-i-use-id-with-my-own-osm-server
>
> Thanks, Bryan
>
>
>
>> On Jun 3, 2016, at 7:54 PM, Stadin, Benjamin
>> > > wrote:
>>
>> Hi list,
>>
>> I¹m on a quest to setup an own instance of OSM, altogether with Nominatim
>> and iD editor. iD should communicate with this very instance of OSM and
>> not with the global OSM website.
>>
>> While I¹ll continue to digg into the code, do you have some valuable
>> pointers for me about installing and configuring these three? While the
>> website is documented well, this triplet is not. It doesn¹t seem to be
>> common (understandably, but I really need to do this).
>>
>> Cheers
>> Ben
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/dev
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] mail notification from changeset comments

[Simon Poole]

Am 02.01.2016 um 06:43 schrieb Gerd Petermann:
> Hi all and a happy new year!
>
> I wonder why mails produced by changeset comments are treated different to
> those written by users:

Because they are not mails generated by the internal message system, see
https://github.com/openstreetmap/openstreetmap-website/issues/908

Simon



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

Re: [OSM-dev] Using native social SDK for signing in to OSM on mobile

[Simon Poole]

If I understand Ilya correctly what he wants to avoid is (the hassle of)
the authorisation step when using OAuth. During this process you need to
login to openstreetmap.org with your credentials and then confirm that
the app is allowed to access the API on your behalf.

To see what is involved in practical terms you can try to use the HOT
task manager, maproulette etc (or on a mobile device Vespucci, I assume
Go Map! uses OAuth too, as any current third party app for OSM should).

The authorisation is a one time process (per app) and as such I'm not
quite convinced that the whole discussion isn't a solution looking for a
problem, but Ilya is correct in that it does involve the hassle of
people remembering their google/FB/whatever password. Naturally on a
mobile device you want to minimize typing in any case so I'm mildly in
support of at least investigating what this would entail (it is unlikely
that we would use a proprietary solution in Vepsucci though, on other
devices and with other apps the trade-offs might be different).

The above is a separate but related issue to making the signup process
"mobile friendly"  see
https://github.com/openstreetmap/openstreetmap-website/issues/894 for a
longish discussion.

Simon

Am 24.12.2015 um 15:58 schrieb Greg Troxel:
> Ilya Zverev  writes:
>
>> This can be made a part of a policy for allowing apps to use OSM
>> official social accounts.
> Can you explain what you mean by "OSM official social accounts"?
> Perhaps it is just me that doesn't get it, but I am not following what
> you really mean.
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Why is ford=yes not rendered in the default style?

[Simon Poole]

Dave

Currently the rendering database is created with static rules that map
OSM keys to columns, Mateusz has already pointed you to the config file
for that, the likely solution for the issue is to re-import and besides
the existing mapping method to import all tags (or at least nearly all)
in to the key/value storage column type that Postgres provides. But the
whole migration needs to be thought out and tested and given the current
developments on the output side of things may need rethinking again
before being deployed.

Simon

Am 26.11.2015 um 19:58 schrieb Dave F.:
> Mateusz , Simon et al
>
> I admit I'm a bit of an outsider on this (I prefer going out,
> collecting data to upload) but I'm a bit surprised by these 'it's not
> possible really' comments.
>
> A few years ago it was announced that the carto schema (or whatever
> you want to call it) was to be 'overhauled to make it simple to edit
> so everybody could lend a hand'. It appears, from what's been said
> here, that it either didn't improve or it's gone back to square one.
>
> In simple terms could you explain (or point to a relevant page) what
> the render database is & why it needs 'importing' and what hstore is
> .A quick google & it appears to be just k=v data storage, as is used
> in OSM database. Is that all it is?
>
> Icons to POIs have been added to the carto in the past few updates (ie
> amenity=fountain), what's different about ford=yes? I find this mildly
> disappointing. It was announced a long while back that this tag was
> superseding highway=ford. I & others spent time changing them over
> only for it to actually reduce the quality of the 'standard' map.
>
> Dave F.
>
>
> On 26/11/2015 16:47, Mateusz Konieczny wrote:
>> On Thu, 26 Nov 2015 12:20:13 +
>> "Dave F."  wrote:
>>
>>> Hi
>>>
>>> @Holger: Could you explain why it's "technically not possible"? It
>>> seems strange just this one node can't be rendered.
>> Currently only tags listed at
>> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style
>>
>> may be used to generate Standard map layer.
>>
>> Changing this is not trivial - for start "There's nothing published
>> about moving a style to hstore and making schema choices based on
>> data." to quote
>> https://github.com/gravitystorm/openstreetmap-carto/issues/1975
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>




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

Re: [OSM-dev] Why is ford=yes not rendered in the default style?

[Simon Poole]

Am 26.11.2015 um 13:20 schrieb Dave F.:
> Hi
>
> @Holger: Could you explain why it's "technically not possible"? It
> seems strange just this one node can't be rendered.
>
>
Because the rendering database doesn't contain the information and any
strategy to fix it requires a reimport of the database. So naturally
"technically not possible" is not really correct, it is simply dependent
on other things happening.



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

Re: [OSM-dev] New Map Style feedback

[Simon Poole]

Anything with hairpins, small squares or adjacent roads at zoom 15 and
16 (there's plenty in Ticino to point to somewhere nearby, including the
same symptom with tertiary, aka yellow blobs (you can use
http://tile.openstreetmap.fr to verify).

Am 02.11.2015 um 11:07 schrieb Martin Koppenhoefer:
>
> 2015-11-02 10:51 GMT+01:00 Simon Poole  <mailto:si...@poole.ch>>:
>
> -1 given that you can always find specific situations in which a one
> size fits all rendering fails, in the previous style there are tons of
> while blobs made out of residential class roads, didn't stop anybody
> from using the map.
>
>
>
>
> examples? IMHO, a residential road has to have some minimum width, a 2
> metres wide alley (total width, no pavement) in a historic town center
> should be tagged as an alley, for instance. Similarly, a
> highway=pedestrian should be a road that is pedestrianized, not a
> small footway/alley inside a "pedestrian" zone.
>
> Cheers,
> Martin



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

Re: [OSM-dev] New Map Style feedback

[Simon Poole]

Am 02.11.2015 um 10:03 schrieb Martin Koppenhoefer:
>
>
> +1, especially tertiary roads now tend to merge into blobs, e.g. here: 
> http://www.openstreetmap.org/#map=17/41.85901/12.49464
>
>
-1 given that you can always find specific situations in which a one
size fits all rendering fails, in the previous style there are tons of
while blobs made out of residential class roads, didn't stop anybody
from using the map.



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

Re: [OSM-dev] New Map Style feedback

[Simon Poole]

Am 02.11.2015 um 09:40 schrieb Maarten Deen:
>
> I agree that the abandonging of the blue for motorways is a bad
> choice. It is not only a british color, motorways are signalled in
> blue also in lots of other countries in europe.
And in lots of countries in Europe they are signposted in green. I'm not
quite sure why we are being held ransom to a questionable decision which
was made (not so long ago) by an unrelated third party. Which
interesting enough however doesn't use every imaginable colour for their
road network either
https://www.ordnancesurvey.co.uk/osmaps/#53.00818632749056,-1.4402046835289466
and essentially only differentiates between three road types.
> But that is not really the issue. It is not that a colorscheme should
> follow the colorscheme of a particular country per se. The current
> color scheme just makes it hard to distinguish roads. Teritary roads,
> being white, are all but unrecognizable. Looking at motorways, trunk
> roads or primary roads, I can not tell one from the other, except when
> I see two next to eachother.
> Furthermore, on high zooms, roads have gotten too fat. It makes the
> map look bulky.
>
> The colorscheme for roads is defintely a step back from the previous.
I think you'll find that most find that it is a big step forward. if you
go back and look at the material provided during the (very very public)
development and discussion of the changes, or just compare with the
French style (which uses the previous colour scheme), it is very obvious
that the road network is rendered substantially better now. Your straw
man: "I have to be able to recognize each single road type in isolation"
is simply not realistic for a map that is supposed to include everything
else too.

Simon



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

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Simon Poole]

Am 30.10.2015 um 13:31 schrieb Maarten Deen:
>
> So you have to have some kind of mechanisme to decide when to show
> name:en (which I want to see for e.g. Afghanistan) and when to show name.
>
That is simple, we live with some people not being completely happy :-) *

Seriously the whole point is exposing questionable tag values then they
get fixed, so if Gravelines has name:nl=Grevelingen tagged but in
reality that should be old_name:nl=Grevelingen the best way to get it
fixed is to show the wrong value on the map.

Simon

* even an imperfect language specific map is likely going to make more
people happy than now




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

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Simon Poole]

Am 30.10.2015 um 11:10 schrieb Martin Koppenhoefer:
>
> 2015-10-30 10:52 GMT+01:00 Christoph Hormann  >:
>
> So far use of vector tiles seem to primarily
> have lead to the following effects:
>
> - improved tile serving efficiency
> - a larger bandwidth of style variations
> - tighter contraints in basic styling decisions beyond what is already
> imposed by the OSM data model
>
>
>
> some additional points that come into mind:
>
> - vector maps are consuming more energy to display (because have to be
> calculated/rendered) -> problem on mobile devices, but also generally
> a problem because every client has to spend energy on calculating the
> "same" image (admittedly depends how many different styles there are,
> and how many people are looking at them until the underlying data
> changes), so globally (i.e. wikipedia use and not some "niche"
> usecases) this means really a lot of wasted energy.
>
> - are likely slower to display (for the same reason), although this is
> depending on different factors (e.g. if you have internet connection
> and how fast it is (vector maps likely scale better for offline use),
> how complex the style sheet is, etc.) -> generally vector maps require
> more ressources, newer more capable client devices.

I don't think anybody is contemplating moving completely away from
server-side tile rendering osm.org at this point in time,  using vector
tiles pre-rendering will likely simply be a further option.

I kind of half agree with Christoph, but I think the perspective that
the vector tiles are a complete replacement for a style specific
rendering database is likely simply wrong. So while vector tiles allow
to produce a group of related styles where you previously simply had
one, if you are doing something completely different you will not be
able to use the same tile set. Naturally, in a wide sense of the word,
there is likely a substantial amount of economic pressure to reuse what
is already there which might lead to really different styles becoming
rarer than they are now . Obviously Andy, Christoph, Richard et al know
a lot more about this than I do. 

Simon


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

Re: [OSM-dev] osm2pgsql polygon handling semantic?

[Simon Poole]

Am 20.10.2015 um 09:47 schrieb Sven Geggus:
> Paul Norman  wrote:
>
>> For the osm2pgsql pgsql backend, a polygon is formed when a way is 
>> closed and the tag transform sets a polygon flag. If either of these is 
>> false, it is a linear feature.
> ... which is then inserted into planet_osm_line, right?
>
> For some reason I would have expected the feature to be discarded in this
> case.
>
Roundabouts? Or in fact any other way that is closed but clearly a
linear feature.

Simon



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

Re: [OSM-dev] proposal for mechanical edit reg. power_source + generator:source

[Simon Poole]

I would have thought that it is obvious, but perhaps not. This
discussion clearly belongs on the tagging mailing list and not here.

Simon

Am 13.10.2015 um 22:25 schrieb François Lacombe:
>
> (Sent from phone)
>
> Hi Gerd,
>
> Such an edit can improve data consistency and your idea sounds good.
>
> As a member of the team who supported the power refinement proposal
> including the generator: source key, I just warn regarding the
> generator value which was used instead of power=plant.
> Power_source or generator:source should be used on devices which are
> generating power.
> May we can take advantage of such an edit to move this information on
> devices instead on buildings or sites ?
>
> All the best
>
> François
>
> Le 13 oct. 2015 9:32 PM, "Frederik Ramm"  > a écrit :
>
> Hi,
>
> On 10/13/2015 08:10 PM, Gerd Petermann wrote:
> > my motivation is simple:
> > JOSM claims that the old tag should not be used,
> > the wiki is also clear:
> > "Use generator:source
> > =*instead."
>
> Yes, but JOSM presets and Wiki pages are not made by the community
> as a
> whole, and can never serve as a reason for running a mechanical
> edit. It
> requires only a very small number of people to devise a silly
> preset or
> "vote" a tag to be deprecated; this absolutely must not lead to others
> mass-editing OSM according to the wishes of that minority.
>
> > I assume that I am not the only JOSM user who is wasting
> > time looking at these obsolete tags,
>
> In that case, a change in JOSM would be the best solution.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org
>   ##  N49°00'09" E008°23'33"
>
> ___
> dev mailing list
> dev@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/dev
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] SRTM GL1 contour and hillshade available

[Simon Poole]

Yves, maybe it is just my eyes playing tricks, but the contours on
opensnowmap.org seem to be systematically offset by bit from where they
should be, you can see this best when looking bodies of water, for
example:
http://opensnowmap.org/?zoom=16&lat=47.40045&lon=8.36286&layers=&marker=false

Simon

Am 21.09.2015 um 09:54 schrieb yvecai:
> Hi,
> I have a 216GB .zip file full of contours shapefiles in projection
> 3857 (simplified 4 meters with ogr2ogr Douglas-Peucker), along with a
> 80GB geoTiff hillshading raster that correspond to the DEM described
> here:
> http://blog.opensnowmap.org/post/2015/07/11/New-hillsahding-on-OpenSnowMap.org
>
>
> This time, I used the complete SRTM 1 ar-second released recently and
> including the middle east, for a coverage from 56° south to 72° north
> with the help of EU-DEM and ASTER.
>
> Please drop me an email in private if you are interested in
> downloading the files, I'll have to remove them from the server later
> this week.
>
> Regards,
> Yves
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] Languages

[Simon Poole]

Hello Ramneek

You are not quite clear if you want translations for a new project or if
you want to add translations of tags to an existing project.

If it is the later:

- the OpenStreetMap website is translated on
http://transwiki.org/wiki/index.php?title=Main_Page
- the iD editor (including its presets)
https://www.transifex.com/projects/p/id-editor/
- the JOSM editor https://translations.launchpad.net/josm/+translations

Note in all cases the actual tag values are not translated, simply the
labels used to identify them in the editor presets.

There is further a more principle problem that in OSM real world objects
tend to be identified by tag combinations that have grown historically.
It is not guaranteed that literal translations of individual tag keys
and values will actually result in a better and easier user experience
than simply leaving them in English.

If you are looking for translation tools/platforms for a new project,
transifex seems to be the most popular currently.

Simon



Am 20.04.2015 um 08:33 schrieb Ramneek Paul Singh:
> Can anyone help in listing the tools that could help me conversion of
> the tags in he local language i want and can i edit it ?
> --
> Ramneek Paul Singh
> http://ramneekpaulsingh.wordpress.com
> " Failure is the opportunity to begin again more intelligently "
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 



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

Re: [OSM-dev] Can't render map on Android's webview

[Simon Poole]

There are dozens of things that could be wrong, but for starters: have
you actually enabled JS in the Webview?

(Naturally a code sample would make things a -bit- simpler)

Simon

Am 22.03.2015 um 21:00 schrieb Arseniy Taradonov:
> Hi 
>
> My app generates a html report with OSM (via leafletjs). OSM looks
> well when I open report in FF for Android and in any browser on my
> desktop. The OSM map isn't visible when open the report via the
> WebView component from my app. Can someone tell if it is a bug or the
> OSM isn't allowed for the Adndroid WebView component?
>
> Thank you 
> Arseny
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] osm2pgsql - error loading planet

[Simon Poole]

Do you have enough disk space?

I believe we have seen similar errors due to running out of space (the
COPY command is essentially bulk loading data in to tables and seems to
not give particularly helpful messages when things go wrong).

Have you tried something really small, say Luxembourg or so?

Simon



Am 16.03.2015 um 10:28 schrieb angelo de angelis:
> Dear members,
> 
> it's many weeks that i'm trying to import the latest versione of the
> planet-latest.osm.pbf into postgresql/postgis using osm2pgsql without
> success.
> After many many attempts i tried to import a smaller version of the
> dataset (europe-latest.osm.pbf), same bad result.
> 
> Just some details on my configuration:
> 
> Hardware: PC 64-bit 8-core 32 gb ram
> OS: Ubuntu 14.04.2 LTS
> postgresql:  PostgreSQL 9.3.6 on x86_64-unknown-linux-gnu, compiled by
> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit
> postgis: POSTGIS="2.1.2 r12389" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel.
> 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26"
> LIBXML="2.9.1" LIBJSON="UNKNOWN" RASTER
> osm2pgsql SVN version 0.85.0 (64bit id space)
> 
>  My last command was:
> 
> osm2pgsql --create -s -v -C 28000 --cache-strategy sparse
> --number-processes 6 -I --flat-nodes ./nodes.cache
> --disable-parallel-indexing -l -d gio_reference -U gio -W -H localhost
> -P 5432 /Data/europe-latest.osm.pbf
> 
> Here is the error:
> 
> Processing: Node(1432818k 1007.6k/s) Way(65018k 27.54k/s) Relation(0
> 0.00/s)pgsql_ways_set - bad result during COPY, data 139191086
> {1525470973,1525469649,1525469626,1525469616,1525469608,1525469597,1525469594,1525469591,1525469590,1525469586,1525469583,1525469571,1525469573,1525469588,1525469593,1525469596,1525469613,1525469617,1525469618,1525469629,1525469634,1525470940,1525469638,1525469639,678216143}
> {"z_order","0","highway","track"}   f
> 
> Error occurred, cleaning up
> 
> I think it's a bug but found no informations neither solutions on forums.
> 
> Does anybody experienced a similar issue? Does anybody solved it? Please
> let me know.
> 
> Thanks, Angelo.
> 
> 
> 
> 
> 
> -- 
> al mondo ci sono solo 10 tipi di persone: quelle che capiscono il
> binario e quelle che non lo capiscono
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 



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

Re: [OSM-dev] Vespucci 0.9.5.1.929: Tag presets

[Simon Poole]

Downloaded presets are stored on device (including any referenced
icons), so you don't have to download them again except if you want to
update (which includes the icons with other words you simply need to
specify an URL for the icon).

See https://github.com/simonpoole/beautified-JOSM-preset for two
versions of standard presets, one that is included in the vespucci build
and one which is downloadable directly (in principle there is a further
way of installing on device presets, but that code hasn't been looked at
in a very long time).

Simon

Am 06.02.2015 um 11:35 schrieb hike39:
> Hi,
>
> I'm new to this mailing list but I hope that I'll get here some help
> concerning Vespucci tag presets.
>
> I've just started to test this application. In general it meets my
> requests. Now I tried to add an own tag preset. To produce the
> preset.xml file I used the HOT visual tag chooser
> (http://visualtags.hotosm.org/). Everything went fine with the creation
> and the upload to my smartphone.
>
> But now my questions:
>
> - must that tag preset file downloaded every time, when I start the
> application or is it stored somewhere on my device?
>
> - is it possible to reference for the tag icons a local directory?
>
> If this mailing list is not the right platform to discuss this matters,
> then please let me know where to place my questions.
>
> Greetings
>
> hike39
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] osm2pgsql: append-mode (error message)

[Simon Poole]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

You shoule merge the 3 files in advance and import once. IMHO the merge option 
simply retains existing data but does not actually "merge" it.

On 31. Dezember 2014 15:45:58 MEZ, Stefan Mohr  wrote:
>Hi everyone,
>
>
>
>I am relatively new to using OSM data and osm2pgsql and have been doing
>some
>testing during the last few weeks. I am using the following command
>lines
>and I am pretty not sure, if I am doing it in the right way:
>
>
>
>osm2pgsql --verbose --create --slim --cache 4096 --prefix planet_osm
>--database osmtest --username gis --host localhost --hstore
>--extra-attributes --style /gis/maps/planet/style/default.style
>--number-processes 4 --bbox 7.85,51.50,11.32,55.06
>schleswig-holstein-latest.osm.pbf
>
>
>
>osm2pgsql --verbose --append --slim --cache 4096 --prefix planet_osm
>--database osmtest --username gis --host localhost --hstore
>--extra-attributes --style /gis/maps/planet/style/default.style
>--number-processes 4 --bbox 7.85,51.50,11.32,55.06
>hamburg-latest.osm.pbf
>
>
>
>osm2pgsql --verbose --append --slim --cache 4096 --prefix planet_osm
>--database osmtest --username gis --host localhost --hstore
>--extra-attributes --style /gis/maps/planet/style/default.style
>--number-processes 4 --bbox 7.85,51.50,11.32,55.06
>niedersachsen-latest.osm.pbf
>
>
>
>The result should be a "merging" of 3 osm data files, the first line is
>doing a good job , but during the second line there is an error:
>
>
>
>Reading in file: hamburg-latest.osm.pbf
>
>Processing: Node(2156k 113.5k/s) Way(405k 27.00k/s) Relation(0
>0.00/s)COPY_END for COPY planet_osm_ways FROM STDIN;
>
>failed: ERROR:  duplicate key value violates unique constraint
>"planet_osm_ways_pkey"
>
>DETAIL:  Key (id)=(3075476) already exists.
>
>CONTEXT:  COPY planet_osm_ways, line 193
>
>
>
>I would be glad if anyone could tell me, what I have missed and what I
>am
>doing wring here? Thanks a lot,
>
>Stefan
>
>
>
>
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev

- --
Written with a pen on a Galaxy Note 10. I
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQE6BAEBCgAkBQJUpCQ+HRxTaW1vbiBQb29sZSA8c2ltb25AcG9vbGUuY2g+AAoJ
EEchcRCS4oLq3D8IAKJ8NHic/BlEE95vcShHb5lhveqLt72VZVA3UmIvhWsPNp0U
nCtq6044Fo0yfwnPZ9P9BTmraB3PGQ3uKVoQeAMVbU96R9fczUVi+1G559/tB8nz
LgfaI3+yDMt4MVSpbpeRcyc4cx4oHuPwU/TGGv88X3SC6558PFHnNKP5RtutkdtU
ua7a3qlEYGYZuh+UhXS/ED4K8hGsbzs369aksxBuraAQzQbCvsCS54/+QZjcVxaf
uWqbLrdG4jmgm8zixlQuBj+S/Fnlk9W378cLhMRikr/0ilsTPC5/TS7nDch+iZa6
iFoA0Y+kZg7x/L8xjP7vpOXWPST7Bbi/LZjVYEw=
=RY05
-END PGP SIGNATURE-


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

Re: [OSM-dev] Looking for OSM Licensing Clarification

[Simon Poole]

Joel, please stop trolling. Richard gave you a clear answer, much more
polite than I would ever be, pointing out:

a) it really depends on the particulars of your point (2)
b) this is the completely wrong place for such a discussion

Simon

Am 20.10.2014 04:09, schrieb Joel ...:
> Understood. My use case is prohibited. Remove the deception on the
> wiki.openstreetmap.com front page. It does not help the business
> because businesses succeed by way of customer service, respecting
> others, showing diginty, respect and morals. To refresh your memory, the
> first few lines of the page reads: 
> 
> "*Welcome to OpenStreetMap*, the project that creates and
> distributes free  geographic
> data for the world. We started it because most maps you think of as free
> actually have legal or technical restrictions on their use, holding back
> people from using them in creative, productive, or unexpected ways."
> 
> 
> 
>> Date: Sun, 19 Oct 2014 21:35:58 -0400
>> Subject: Re: [OSM-dev] Looking for OSM Licensing Clarification
>> From: rich...@weait.com
>> To: audiof...@outlook.com
>> CC: dev@openstreetmap.org
>>
>> The OpenStreetMap license ODbL is what is known as a Share Alike
>> license. In that class of licenses, one is granted more permissions
>> when one shares and shares alike. If, on the other hand, one wishes
>> to keep things for ones exclusive benefit, ones permissions are more
>> limited, perhaps even to a null set.
>>
>> Again, in very broad terms, one has more freedom if one uses the
>> OpenStreetMap data without changing it. Combining OpenStreetMap data
>> with other non-OpenStreetMap data sets, is an area where the
>> obligations to share are deliberately strong.
>>
>> The details matter in this subject area, and it is a benefit for you
>> to understand your obligations from the start. Please consider giving
>> more details and holding further discussion on the legal-talk@ mailing
>> list[1], which is the ideal location for this topic.
>>
>> [1] https://lists.openstreetmap.org/listinfo/legal-talk
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 



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

Re: [OSM-dev] world wide PBF exports corrupt

[Simon Poole]

From a size perspective the dumps here
http://planet.openstreetmap.org/planet/experimental/ look ok.

Am 20.10.2014 00:04, schrieb Peter K:
> Hi there,
>
> it looks like all pbf export servers I know have no recent or corrupt
> pbf exports (small file size of 17gb or 6gb instead of 27gb):
> http://wiki.openstreetmap.org/wiki/Planet.osm
>
> Is this a known issue of some export tool? Or do you know an alternative?
>
> (Also it looks like there are no daily export servers anymore?)
>
> Regards,
> Peter.
>




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

[OSM-dev] Transifex OpenStreetMap Organisation

[Simon Poole]

A week or two back I created the OpenStreetMap organisation on transifex
as an umbrella for the vespucci project, but naturally open to all OSS
that wants to use transifex for translation purposes.

The main advantage is likely that your project will get exposure to
translators that already know OSM lingo. I currently wouldn't recommend
moving existing projects to the new organisation at this point in time
except if you have a very small number of translators. There doesn't
seem to be an automatic way to move/copy translators together with a
project resulting in having to invite all translators back to the
project. Outside of that feel free to contact me if you would like to
move your project or create a new one.

In case it isn't clear: this is not an official OSMF activity nor
endorsement of transifex and there are other, just as good or perhaps
better alternatives. For vespucci it was simply the best solution.

Simon



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

[OSM-dev] Wikimedia Foundation Job Offering

[Simon Poole]

I believe this hasn't actually been posted here (it has been on
osmf-talk and a couple of other places):

http://boards.greenhouse.io/wikimedia/jobs/24983?t=4w5iyb#.VBIBukiFUZw



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

Re: [OSM-dev] Minutely updates format error?

[Simon Poole]

From the error message I would guess a corrupted diff, given that my
server is running normal and there hasn't been a barrage of complaints I
expect a one off on your machine. I would suggest deleting the diff and
resetting the state file a bit.

Simon

Am 03.08.2014 05:21, schrieb Lynn W. Deffenbaugh (Mr):
> For the past 8-12 (maybe 24) hours, my tile server has been failing to
> update.  The error reported is:
> 
>> Processing: Node(0k 0.0k/s) Cache(Ch:0.0%@0.0%u fh:0.0%) Way(0k
>> 0.00k/s) Relation(0 0.00/s) Why:NodeStart
>> Processing: Node(360k 2.0k/s) Cache(Ch:0.0%@2.9%u fh:98.9%) Way(0k
>> 0.00k/s) Relation(0 0.00/s)
> 
>> Entity: line 395041: parser error : Input is not proper UTF-8,
>> indicate encoding !
>> Bytes: 0xD8 0x51 0x72 0x20
>>   https://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Towards a unified and simple indoor mapping scheme

[Simon Poole]

Am 20.06.2014 14:16, schrieb Christopher Baines:
> On 20/06/14 10:07, Simon Poole wrote:
>> In the aftermath of some discussion at SOTM-EU (see the presentation by
>> Thomas Graichen), I've jotted down some of my thoughts on the subject
>> here http://forum.openstreetmap.org/viewtopic.php?id=25961
>>
>> IMHO the most important thing (besides getting rid of the conflicts) is
>> to enable the typical OSM progression in mapping from rough to more
>> detailed to insane :-).
> Firstly, would you like discussion on this to be on the discussion page
> on the wiki, the forum post, on this mailing list, or somewhere else?
>
>
Given that we don't have a real proposal yet, I would suggest till that
point in time the forum would be the obvious place, once something is
nailed down enough for a proposal then potentially the discussion page
on the wiki.

Could you repost your message there?

Simon



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

[OSM-dev] Towards a unified and simple indoor mapping scheme

[Simon Poole]

In the aftermath of some discussion at SOTM-EU (see the presentation by
Thomas Graichen), I've jotted down some of my thoughts on the subject
here http://forum.openstreetmap.org/viewtopic.php?id=25961

IMHO the most important thing (besides getting rid of the conflicts) is
to enable the typical OSM progression in mapping from rough to more
detailed to insane :-).

Simon



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

Re: [OSM-dev] places of business listings

[Simon Poole]

Am 18.06.2014 21:57, schrieb Sachin Dole:
..
> cool. Now, I just wonder who owns that site and if they have any
> licensing requirements for what I would do on their site.

Every site targeted at a German audience*, including non-commercial
ones, is required to have a so called "Impressum" stating who operates
the site etc.. If you scroll down to the bottom you will find the link
that will give you everything you want to know and more.

As to the legality, there is just no way POIs from 4sq can be copied
into OSM. However I suspect what the operator is simply doing is linking
from the OSM POI to the corresponding 4sq meta information which is
likely OK from an OSM pov, and maybe it is OK with 4sq too.

Simon

* don't get me started on the fact that OSM doesn't have it.



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

Re: [OSM-dev] osm2pgsql planet_osm_ways sudden shrinking :(

[Simon Poole]

Doesn't seem to be a general issue

http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/postgres_size_gis_9_1_main.html

my server

http://hz3.poole.ch/munin/localdomain/localhost.localdomain/postgres_size_gis.html

Simon


Am 23.05.2014 10:47, schrieb Christian Quest:
> On 2 different OSMFR tile servers we recently got the same problem:
> planet_osm_ways is suddenly "shrinked". We have no idea of what can
> cause this.
> It looks like the whole table is truncated.
> 
> You can have a look for exemple here:
> http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/postgres_size_ALL.html
> http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/postgres_size_ALL.html
> 
> Are we the only ones to face this strange problem ?
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 



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

Re: [OSM-dev] Sending messages to users

[Simon Poole]

My 2 cents:

I think making permission to send mail to a user contingent on the user
in question authorizing the application to do so is probably the way
forward. I would suggest as a rule always making it optional for
participation in any OSM related activity.

Alternatively we could simply allow access to the e-mail address (as
above) instead of adding a public API to the message system, there are
just some privacy issues that I would see with that.

Now there's the just the small matter of actually coding it 

Simon

Am 05.05.2014 18:27, schrieb Serge Wroclawski:
> Simon,
>
> An example of the kind of thing we'd like to send messages.
>
>  Sending messages that you should try a harder challenge
>
> For example, if the average time to fix a task in challenge foo is 30
> seconds, and you only take 20 seconds, maybe you should try something
> harder
>
> Sending messages about false fixes
>
> If I claim to have fixed 2000 tasks, but then the server sees that all
> 2000 still remain as problems, we want to send a message
>
> This isn't an exhaustive list, but it's the kind of thing where we'd
> like to reach out to OSM users, and right now, there's no way to do
> that without implementing it ourselves.
>
> - Serge
>
> On Mon, May 5, 2014 at 10:43 AM, Simon Poole  wrote:
>>
>> Am 05.05.2014 15:52, schrieb Serge Wroclawski:
>>
>>> The problem is that we are needing to send messages to users. Ideally,
>>> those messages would go through osm.org.
>>>
>> Serge,
>>
>> what exactly is the use case you are thinking of or better: what
>> messages are you thinking of sending? A message API would seem to only
>> be required if we are talking about very high volume (a lot more than
>> the 100 or so welcome messages I send per month).
>>
>> I'not arguing against being able to contact mappers better, quite the
>> contrary (I suggested the API extension which allows editors to show you
>> how many messages you have), just need to understand what your needs are.
>>
>> Simon
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>




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

Re: [OSM-dev] Sending messages to users

[Simon Poole]

Am 05.05.2014 15:52, schrieb Serge Wroclawski:

> 
> The problem is that we are needing to send messages to users. Ideally,
> those messages would go through osm.org.
> 

Serge,

what exactly is the use case you are thinking of or better: what
messages are you thinking of sending? A message API would seem to only
be required if we are talking about very high volume (a lot more than
the 100 or so welcome messages I send per month).

I'not arguing against being able to contact mappers better, quite the
contrary (I suggested the API extension which allows editors to show you
how many messages you have), just need to understand what your needs are.

Simon



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

[OSM-dev] Fwd: [talk-ch] OSM Mappers and developpers invited to the Randa Meetings 2014

[Simon Poole]

We (as in SOSM) have been approached by the organizers of the 2014 Randa
Meeting if OSM developers would like to participate. I think this would
be a good opportunity to work on some larger projects together, one that
cam to mind was OWL, but there are sure to be others.

If there are people from OSM attending I would try and see if the OSMF
could cover some of the costs (aka the accommodation).

Simon


 Original-Nachricht 


Dear all
Randa [1] is a small and beautiful village in the Swiss Alps just two
train stops away from Zermatt with its world famous Matterhorn! The next
Randa Meetings take place from Saturday, 9th to Friday, 15th of August
2014. The association Randa Meetings lead by Mario Fux organises the 5th
Hacking Meeting already.

What are these Randa Meetings?
The goal of the Randa Meetings is to bring groups and people from the
global free software, open source and open data community together for
one week in a nice place to discuss, work and hack on the next big (or
small) thing. Due to its origin so far mainly the KDE community has
participated and we have hosted as much as 50 developers (the house has
a capacity of approx. 100) [2].

The organisers of Randa Meetings provide the place and basic services
such as food, drinks and accommodation (not for free but for a very low
price, see below), meeting rooms and the probably nicest view you can
have for a (developer) meeting. The content comes from the participants.
So you can come with your group and discuss, map or hack on whatever is
important to you.

So do you have a project you are working on within the OSM community?
Bring your people to Randa in August and you will most probably have a
boost for the project. The past meetings have shown that the great
atmosphere and the peaceful surroundings are very positive for the
productivity and focused work. And you can come for just a day or two or
the whole week. It's totally up to you.

Family and friends are welcome, too!
Randa is great also for your family. There are a lot of opportunities
for hiking, mountain biking or just enjoying yourself in a great
panorama. This year we know already from a few bringing their kids along
with them.

What does it cost me?
The accommodation is approx. 20 CHF/person and night (+/-5 CHF) and also
depending on how much sponsoring we can obtain. Family members have to
pay for themself (no sponsored stays).
Food (full board) is provided at 15 CHF/person and day.
Travel expenses are to be covered by the participants. For international
participants on low budget we can provide a special fare train ticket on
request (limited availability).

Interested? Get in contact with us! Pascal Mages (pascal.ma...@sosm.ch)
or Mario Fux (f...@kde.org).
For further information visit http://randa-meetings.ch/

Looking forward to see you in Randa!
Pascal & Mario

[1] http://www.openstreetmap.org/#map=14/46.0999/7.7652
[2] http://community.kde.org/Sprints/Randa


-- 
e-mail signed with CAcert certificate (www.cacert.org)



___
talk-ch mailing list
talk...@openstreetmap.ch
http://lists.openstreetmap.ch/mailman/listinfo/talk-ch



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

Re: [OSM-dev] Heartbleed

[Simon Poole]

Am 10.04.2014 23:42, schrieb Grant Slater:
.
> The probability is extremely low that any user data was compromised,
> but I would not discourage anyone from changing their password if they
> are concerned.
.

There are some indications (as was to be expected) that the
vulnerability was known well before the public announcement

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013






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

Re: [OSM-dev] Longitude/Latitude result different from Google/Bing

[Simon Poole]

Am 18.02.2014 21:13, schrieb Simon Poole:
>   that the position of the cell tower is not actually in the middle of
> the water tower which has a diameter of roughly 30m, but on one side
> of it.
>
Actually as you see here
http://mc.bbbike.org/mc/?lon=-77.24981&lat=39.18456&zoom=18&num=2&mt0=google-satellite&mt1=bing-satellite
it is very clear that the cell tower is a separate structure that is
south west from the water tower that is mapped in OSM at a good 20m
distance.

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

Re: [OSM-dev] Longitude/Latitude result different from Google/Bing

[Simon Poole]

Vince

It is not quite clear what you are getting at. Currently the tower node
is located at  39.1847132, -77.2495875

in OSM and likely the position was derived from bing imagery. The
difference to the position you give is 26 meters (result from an online
calculator that I didn't check myself) which may indicate that the
imagery there is slightly misaligned or that the position of the cell
tower is not actually in the middle of the water tower which has a
diameter of roughly 30m, but on one side of it.

Simon



Am 18.02.2014 20:09, schrieb Vince Berubey:
> Hi,
> If you look at this page, you will see a cell tower at: 39.184556 /
> -77.249806
> http://www.cellreception.com/towers/details.php?id=1230956
>  
>  
> In google map , it shows the same thing when we type 39.184556 -77.249806.
> But, in OpenStreetMap, you see the location of the cell tower is a
> little bit different:
> http://www.openstreetmap.org/search?query=39.184556%20-77.249806#map=18/39.18483/-77.24953
>  
>  
> Do you have an explanation for this? Should I expect OSM to always
> have a longitude/latitude a little bit different that what it really is?
>  
>  
> Thank
>  
>  
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

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

Re: [OSM-dev] Field Paper on a Tablet in the near future?

[Simon Poole]

IMHO is is difficult to see a reason to just move the field paper model 
to a tablet if you actually have tablet plus infrastrusture at least at 
your base camp available. Why not use Vespucci and forget about trying 
to transform something that works great on paper to some where it is 
rather silly.


Simon

Am 05.02.2014 00:31, schrieb Pierre Béland:
Some propositions were made last summer to develop a Field Paper 
Application on a tablet.


HOT is looking at various ways for humanitarian operating in various 
countries to collect data about various infratructures. Discussions 
recently with various humanitarian organizations show great interest 
of these organizations for such an application, especially if it did 
include Map Download and Offline editing.


I would like to know who is working on such projects actually and if 
any progress on this.


Should we see such application available for the Android platform soon ?
Pierre


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


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

[OSM-dev] Vespucci 0.9.3 (BETA)

[Simon Poole]

I'm in the process of preparing a new release for the google app store.
This version contains a number of bug fixes and the  following notable
additions or improvements:

  * orthogonalize function for ways similar to iD/P2. It will work on
angles within 10° of 90° and on closed and open ways. It does not
simplify ways as iD does.
  * improved styling of map data
  * mid way handles to add nodes by dragging. This works similar to JOSM
and iD: dragging the centre of ways will automatically insert a node,
handy for improving the geometry of ways
  * large touch/drag area for selected nodes. This is an attempt at
making it easier to move a node to a position without obscuring it with
your finger. The default for this is off, if you want to test this you
need to turn it on in the preferences.


It would be nice to get some feedback on the last two additions. In
particular if they work for you or need further tuning.

The current build can be downloaded from
[url]https://code.google.com/p/osmeditor4android/downloads/[/url]

PS: mid January we will be relocating the download location due to
google no longer supporting downloads from google code.**




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

Re: [OSM-dev] iD editor damaging landuse polygons

[Simon Poole]

John, thanks for the update, even if we tend to sound a bit negative, we
all appreciate the work you are doing on iD.

Simon
 
Am 26.09.2013 22:12, schrieb John Firebaugh:
> In addition to issue #542, the problem of damage to large areas was
> exacerbated by another
> issue: https://github.com/systemed/iD/issues/1693. The effect of #1693
> was that small areas (buildings, parks, etc.) would sometimes be
> rendered below larger areas, meaning that when a user tried to select
> the smaller area, the landuse would be selected instead. This has been
> fixed in iD 1.2.0 -- please keep an eye on this issue and see if this
> fix reduces the frequency of damage. I'm hopeful that it will make a
> significant improvement.
>
> Implementing a fix for #542 is a more complex affair, but among the
> top priorities for iD. Thanks for your patience and understanding that
> no editor is perfect.
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

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

Re: [OSM-dev] iD editor damaging landuse polygons

[Simon Poole]

It is not really a bug, it is simply a (serious) usability issue. To 
recreate


- zoom in on a landuse residential area with buildings (or roads ...)

- continue to zoom in till you no longer see the outline of the landuse 
and just a building


- select the building

- click on the background to deselect the building

- pesky radial menu appears again

- either engage in wild clicking to make the menu go away or press for 
example "q" 


The basic issue is that you get no feedback that you now actually edited 
an object the size of Paris or similar.


Simon


Am 13.09.2013 17:15, schrieb Pieren:

Hi,

We get more and more feedbacks on the French community about landuse
polygons damaged by iD editor. They can be partially orthogonalized
(squared ?) or tags replaced by fancy new values, e.g.
"landuse=residential" by "building=yes"..

It seems that this problem is already reported here
https://github.com/systemed/iD/issues/542
since 8 months...

Even though it is not reported as a bug (I was unable to reproduce it
myself), is some action planned in a short term ?

Pieren

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



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

Re: [OSM-dev] osm2pgsql and timestamp as data in Postgres?

[Simon Poole]

If I remember correctly the relevant code is simply missing from  the
.pbf parser.

Simon

Am 09.07.2013 16:26, schrieb Stefan Keller:
> Hi Simon
>
> 2013/7/9 Simon Poole :
>> I believe there is a bug that the timestamps don't get imported from
>> .pbf files. Should work fine with xml.
>
> We opened a ticket here https://trac.openstreetmap.org/ticket/4894
>
> Yours, Stefan
>
>
> 2013/7/9 Simon Poole :
>> I believe there is a bug that the timestamps don't get imported from
>> .pbf files. Should work fine with xml.
>>
>> Simon
>>
>> Am 09.07.2013 12:21, schrieb Stefan Keller:
>>> Hi Paul
>>>
>>> 2013/7/9 Paul Norman  wrote:
>>>> The -x|--extra-attributes option will include this metadata. You
may want to
>>>> add the columns to your .style file, and you will need to if you're not
>>>> using hstore.
>>> Thanks for your reply. That's what we're already doing:
>>>
>>> osm2pgsql --create --slim --extra-attributes --database $DB_NAME \
>>>--prefix osm --style /usr/local/share/osm2pgsql/terminal.style \
>>>--username $DB_USER --port $DB_PORT --hstore-all
--input-reader pbf \
>>>"$OSRM_BIN_DIRECTORY/$(basename $CH_OSM_URL)"
>>>>/dev/null
>>>
>>> Unfortunately, the hstore field contains e.g. osm_id, osm_version -
>>> but no timestamp!
>>>
>>> Yours, Stefan
>>>
>>> 2013/7/9 Paul Norman :
>>>>> From: Stefan Keller [mailto:sfkel...@gmail.com]
>>>>> Subject: [OSM-dev] osm2pgsql and timestamp as data in Postgres?
>>>>>
>>>>> Hi,
>>>>>
>>>>> Did anyone manage to configure osm2pgsql in order that it stores also
>>>>> the timestamp XML attribute in Postgres - either as separate field
or as
>>>>> key/value in the hstore field? If yes, how can I do that?
>>>> The -x|--extra-attributes option will include this metadata. You
may want to
>>>> add the columns to your .style file, and you will need to if you're not
>>>> using hstore.
>>>>
>>> ___
>>> dev mailing list
>>> dev@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/dev
>>
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] osm2pgsql and timestamp as data in Postgres?

[Simon Poole]

I believe there is a bug that the timestamps don't get imported from
.pbf files. Should work fine with xml.

Simon

Am 09.07.2013 12:21, schrieb Stefan Keller:
> Hi Paul
>
> 2013/7/9 Paul Norman  wrote:
>> The -x|--extra-attributes option will include this metadata. You may want to
>> add the columns to your .style file, and you will need to if you're not
>> using hstore.
> Thanks for your reply. That's what we're already doing:
>
> osm2pgsql --create --slim --extra-attributes --database $DB_NAME \
>--prefix osm --style /usr/local/share/osm2pgsql/terminal.style \
>--username $DB_USER --port $DB_PORT --hstore-all --input-reader pbf \
>"$OSRM_BIN_DIRECTORY/$(basename $CH_OSM_URL)"
>>/dev/null
>
> Unfortunately, the hstore field contains e.g. osm_id, osm_version -
> but no timestamp!
>
> Yours, Stefan
>
> 2013/7/9 Paul Norman :
>>> From: Stefan Keller [mailto:sfkel...@gmail.com]
>>> Subject: [OSM-dev] osm2pgsql and timestamp as data in Postgres?
>>>
>>> Hi,
>>>
>>> Did anyone manage to configure osm2pgsql in order that it stores also
>>> the timestamp XML attribute in Postgres - either as separate field or as
>>> key/value in the hstore field? If yes, how can I do that?
>> The -x|--extra-attributes option will include this metadata. You may want to
>> add the columns to your .style file, and you will need to if you're not
>> using hstore.
>>
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] New database server

[Simon Poole]

I normally stay out of the tech bike-shedding discussions, however I do
want to point out 

- we are aeons away from requiring and running cutting/bleeding edge
hardware (and having to pay for such)

- in the grand scheme of things we are not spending a lot of money on
hardware (on the one hand our sys admins and the OWG are very frugal and
on the other see the first point)

- the amount of money we spend is a lot of money for the foundation, at
least relative to our other spending, however it is extremely unlikely
that we could away with spending less regardless of implementation
(distributed, 3rd party cloud etc etc etc).

- our current setup is fairly straightforward, fancier schemes are very
likely to be more error prone with the associated costs (manpower)

All this said, I would recommend that anybody who actually wants to help
should participate in the OWG and help with the other tech tasks that we
have in abundance.

Simon


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

Re: [OSM-dev] Show Me The Way - Yet Another Live Edit Viewer

[Simon Poole]

Is it "real time" like http://live.openstreetmap.fr/, or does it "cheat"
(like googles pulse)?

Simon

Am 15.04.2013 05:23, schrieb Ian Dees:
> Inspired by Google Map Maker's Pulse, I put together a quick app that
> uses Overpass augmented diffs to show up to 30 way
> creations/modifications every minute. Check it out here:
>
> http://osmlab.github.io/show-me-the-way/
>
> Feel free to make pull requests or file issues against the code here:
>
> https://github.com/osmlab/show-me-the-way
>
> -Ian
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev

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

Re: [OSM-dev] osm2pgsql and mod_tile have moved to git

[Simon Poole]

Besides all the comments that have already been made, I don't think that
unilaterally declaring the licence to be GPL is a particularly good idea.

There is an issue that not stating licence terms and terms under which
contributions can be made would technically make the programs unusable
if we wanted to nit pick.

SImon

Am 03.04.2013 20:39, schrieb Jeffrey Ollie:
> On Wed, Apr 3, 2013 at 10:10 AM, Kai Krueger  wrote:
>> Any comments or suggestions on the development process of these two projects
>> are welcome,
> First off: YAY!
>
> Second, my first pull request submitted :)
>
> Third, I noticed that none of the source code files (at least the ones
> I looked at) have a header with copyright and
> permission information.  If no one objects, I'll put together a pull
> request that add headers like the following:
>
> /*
> Copyright © 2013 OpenStreetMap
>
> This file is part of mod_tile.
>
> mod_tile is free software: you can redistribute it and/or modify it
> under the terms of the GNU General Public License as published by the
> Free Software Foundation, either version 2 of the License, or (at your
> option) any later version.
>
> mod_tile is distributed in the hope that it will be useful, but
> WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General Public License for more details.
>
> You should have received a copy of the GNU General Public License
> along with mod_tile.  If not, see .
> */
>
> --
> Jeff Ollie
>
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev



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

Re: [OSM-dev] Improving the OSM Rails Port

[Simon Poole]

You know you are inviting to a serious session of bike shedding? :-)

Am 30.10.2012 22:41, schrieb Saman Bemel Benrud:
>
>   * Simplify the 'examples' below the search box.
>
Some kind of link/button to a concise help page would be better, the
examples there are always going to look messy.
>
>   * Rethink the "where am I?" and "home" buttons from the home page,
> turn them into a single button that does something more useful
>
I didn't actually know we had a "where am I" link and I suspect nearly
nobody else did either :-).
>
>   * Find a better home for the 'map key' link
>
Wouldn't a on the map link make more sense (in particular since only one
of the layers actually -has- a key)?
>
>   * Find a better home for the 'GPS traces' link
>
Redundant, there is already such a link on the "user" page, IMHO just
get rid of it. Alternatively, if we still consider GPS tracks important,
have it as a further tab.
The user diaries link is not really necessary either (the content is
already included in the "Community Blogs").

The "Documentation" link is a pet peeve of mine, is is a misnomer
linking to the wiki. Part of the wiki is actually documentation, but an
other substantial part would fall in categories "News", "Events" and
similar.

Simon
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] ODbL full history planet

[Simon Poole]

Am 25.10.2012 15:43, schrieb kimaidou:
> Hi,
>
> Looking at this file
> https://github.com/gravitystorm/openstreetmap-license-change/blob/master/extract_loader.rb
>
> It seems if we do not use the --file, --users-agreed nor
> --changesets-agreed options, this will import the whole history file
> into an apidb.
> This looks promising !
> I am not a ruby guy, so I will surely need some time to understand how
> to install and run this file, but I will give it a try. What about
> performance ? Does it handle a big history file ?

AFAIK it took multiple days to import Ireland (which indicates a year or
so for the whole planet).

Simon



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

Re: [OSM-dev] Hello World

[Simon Poole]

Am 13.10.2012 13:55, schrieb Pawel Paprota:
> It is not necessarily about changing WHAT is displayed but changing HOW it is 
> displayed. Current style is simply not up to the standard in terms of 
> esthetics for a project that aspires to be more than a database.
I suspect (well actually I know) that you will find a very wide range of
opinions on your later statement, from supporting having no public map
at all (just a database) to the full blown google look-a-like. That
specific discussion is however very off topic for the dev list.

Simon



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

Re: [OSM-dev] Hello World

[Simon Poole]

Am 13.10.2012 00:40, schrieb Michal Migurski:
>
> How does a new map style typically graduate to use on OSM.org as an option? 
See http://wiki.openstreetmap.org/wiki/Tile_Layer_Guidelines

My personal view on this is that anybody expecting that simply replacing
the current default displayed style with a different one will change
anything is kidding himself in a big way. The pressure to include
everything and the kitchen sink will not go away and instead just
refocus. It might be good idea to change the misleading labelling of the
default style to make it clear that we don't think the standard for an
OSM data derived map should be totally overloaded, but again that is
just me.  

Simon


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

Re: [OSM-dev] Warn data consumers about the need for 64-bit node numbers

[Simon Poole]

The author of the message is the CWG, the LWG was just asked to comment 
on it. And yes, at least a small hint that it may be a good idea could 
probably be sneaked in.


SImon

Am 02.08.2012 19:59, schrieb Andrew:

The last Licence working group meeting ( https://docs.google.com/document/pub?
id=1j4wiDqukbRGNDh9kC-cUL6j3t4NhlcVgancqieHywK0 ) discussed sending an
announcement to our users ( https://hackpad.com/2L8xdm5nMkM#Upcoming-changes-to-
the-OpenStreetMap-licence ) that the licence is changing and encouraging them to
reimport their data. Should we add a reminder that everyone will soon need to
treat node numbers as 64-bit?

--
Andrew


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



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

Re: [OSM-dev] Nominatim data import error: ERROR: DB Error: no such table

[Simon Poole]

You should be installing osm2pgsql from source, most recent version.

See 
http://wiki.openstreetmap.org/wiki/Nominatim/Installation#Compiling_the_Required_Software


Simon

Am 15.07.2012 17:37, schrieb Gabriel Rossetti:

Hi All,

I was told to post my issue here. The original post is here:

http://help.openstreetmap.org/questions/14238/nominatim-data-import-error-error-db-error-no-such-table

When I try to import map data for Nominatim, I get the following error:

...
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
COMMIT
SET
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
ALTER TABLE
Import
Usage error. For further information see:
osm2pgsql -h|--help
osm2pgsql SVN version 0.70.5

ERROR: DB Error: no such table
DB Error: no such table


I get the same thing with osm2pgsql SVN version 0.80.0 (32bit id 
space). The 0.70.5 version is the one installed from Ubuntu's repos 
and the 0.80.0 version was intalled using the kakrueger/openstreetmap 
PPA as described here: http://wiki.openstreetmap.org/wiki/Osm2pgsql. 
Does anyone know why I get this?


I'm running Ubuntu 12.04 64bit Server.

Thanks,
Gabriel



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



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

Re: [OSM-dev] Licence redaction ready to begin

[Simon Poole]

This is slightly off-topic on dev, but anyway please see the discussion here
https://docs.google.com/document/pub?id=1ntJ5zd2oq_EgpFxZCeJPGbCxz1oeeEu4YSmeOmyrSuE

>From a licence point of view reimporting the database is the important
step (if you are actually publishing/distributing the data or products),
that gives you the freedom to licence tiles as you wish as long as you
attribute.

I personally believe that this is really a non-issue, we will literally
have 100s if not 1000s of sites with slightly "wrong" attribution
strings for a long time.

Simon

Am 10.07.2012 03:35, schrieb Paul Norman:
>> From: Richard Fairhurst [mailto:rich...@systemed.net]
>> Subject: [OSM-dev] Licence redaction ready to begin
>>
>> Once it is complete, we will be ready to distribute data under the ODbL
>> and we'll advise of that with a separate announcement. The final pre-
>> redaction dataset available under CC-BY-SA has now been generated at
>> http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has
>> been redacted, any attempt to access it from the API or the site's
>> 'browse' pages will return a response to that effect.
> To transition from tiles derived from a CC BY-SA source to tiles derived
> from a ODbL source will require changing the attribution and regenerating
> all tiles so that CC BY-SA data is not mis-represented as being ODbL data.
> What time period will data be available under dual licenses so that tile
> servers will not have to reload their database then immediately delete every
> cached tile when changing their attribution?
>
> When I discussed this with Frederik awhile back I suggested publishing the
> first post-redaction planet as dual-licensed as well as one week of diffs to
> allow tile servers to continue to serve old CC BY-SA tiles and re-render
> over the course of a week.
>
> At the very least I would suggest distributing the first post-redaction
> planet as dual-licensed for the simple reason that all the information to
> create it will be available as CC BY-SA.
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev




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

Re: [OSM-dev] Max nodes in a way?

[Simon Poole]

The API enforces a limit of 2'000 nodes. 

Simon



Colin Smale  schrieb:

>Hi,
>
>I am working on some gigantic GPX files with hundreds of thousands of 
>points, representing admin boundary polygons. I'm sure these huge ways 
>will break something or cause performance to be dreadful, so I am 
>planning to split the enormous polygons into a number of ways and tie 
>them together in a relation.
>
>What's a reasonable value to assume for the maximum number of nodes in
>a 
>way? 1000? 1?
>
>Colin
>
>___
>dev mailing list
>dev@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/dev

-- 
Sent from my Galaxy Tab with Kaiten Mail.___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [GSoC] Improvements to Vespucci

[Simon Poole]

Is there a preferred way for reporting issues (except spaming this
list)? I just tried it on a 2.2 device and it refuses to start at all
(the release version works).

Simon



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

[OSM-dev] Country extracts from April 1st 2012 full history planet dump

[Simon Poole]

I've updated the extracts in http://odbl.poole.ch/extracts/ to the
latest (and last CC-by-SA 2.0) planet.

Further, I do have extracts for NA, Canada, Africa, Central and South
America that I can provide on demand (it just takes ages to upload).

Simon


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