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

[Peter Wendorff]

Hi Colin,

just stitching a labels-layer and a base layer together would work, but 
most often would not look well.


Map rendering involves deciding which labels to show considering more 
than just the labels, but icons and shields etc. as well to avoid 
overlapping between all of them.


You don't want to get a map where the label overlaps icons.

As names in different languages differ in their need for geometrical 
space on the map, these placement decisions have to be taken for each 
language differently, thus the labels layer would include icons and 
stuff like that as well - even oneway and so on.


Of course it would be possible to do, but the result would look worse 
than our current maps.


regards
Peter

Am 30.10.2015 um 12:41 schrieb Colin Smale:

Can't we have a multi-lingual map by overlaying a base tile with a
transparent text layer in the chosen language? We wouldn't *need* vector
tiles for that, just a bit more storage (bitmap-based text layers should
compress nicely) and clients which can handle the selection and display
of the extra layer, which is pretty commonplace these days anyway).

--colin

On 2015-10-30 12:29, Oleksiy Muzalyev wrote:


I've heard from the OSM operations team's member at the conference
that it is the question of the servers' infrastructure cost.

But if we have a vector-based map itself language selection, that we
could just add tags /name:fr/ or /name: ru/ and have the OSM map of
say New York in French or in Russian for tourists. Or map of Siberia
in German also for tourists, Middle East in English, etc. without any
additions cost on the server side. It is not that difficult to add
such multi-language tags. There could be also the map in Basque,
Catalan, Kurdish, Scots and other smaller (by number of speakers)
languages without any additional cost and without a civil conflict.

I realize that mobile hardware is not enough advanced for that yet and
vector-based technology is only in an development stage.

brgds
Oleksiy

On 30.10.2015 12:06, Maarten Deen wrote:

On 2015-10-30 11:53, Oleksiy Muzalyev wrote:

One of the advantages of the the vector-based map would be the
multilingualism.

For instance at the moment the OSM map of the Middle East is basically
useless for me as I do not know the Arabic alphabet yet. But as far as
I understand and as I heard at the conference the vector-based map
would allow the choice of a language of the map itself.


I do not see how that can not be solved with png-based tiles. You
only have to render the tiles.
The method for detecting which tileset/language to show is the same.

BTW: it is still not as simple as rendering "in a different
language". Then you start rendering a map in English and see names
like "Cologne" or "Brussels"  show up on the map.

Regards,
Maarten

___
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




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

Re: [OSM-dev] Outdated web pages / default pages on some OSM addresses

[Peter Wendorff]

Hi Tom,

even if they have never been published I think a HTTP-Page that has the 
same URL than the HTTPS version should redirect to the HTTPS equivalent 
or show a hint that the https version exists.


If not published somehow URLs are still often shown without protocol to 
a user (well - most often in those case they are prefixed with www.), 
and users are used to not type in the protocol prefix by hand.


regards
Peter

Am 19.04.2015 um 01:18 schrieb Tom Hughes:

On 18/04/15 18:54, Michael Kugelmann wrote:


https://foundation.osm.org/
shows some information that the SOTM 2007 Manchester is over... (which
is correct, indeed   ;-)

http://foundation.osm.org/
shows a "Apache2 Ubuntu Default Page"...


Where have those URLs ever been published as valid URLs for the
foundation web site?

Tom




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

Re: [OSM-dev] [GSoC] Sharing models web application info

[Peter Wendorff]

Hi Kristijan,
(next try, thunderbird unfortunately encrypted the previous attempt,
might have overseen that - if it's not a bug in the Thunderbird UI).

Am 24.03.2015 um 23:28 schrieb Kristijan Trajkovski:
> [...]
> As for scale conversions i think that the main issue would be to find
> out the correct scale based on user's input, so perhaps it would be the
> best to provide a unit standard (for example 1 blender unit = 1 meter)
> and in this way we can defer the required scale to 3d modellers instead
> of trying to guess or approximate scale.

Scaling isn't the only factor, and a robust solution should cope with at
least some sort of changes of the OSM data:

A building may be corrected in its dimensions (half a meter more or less
are often difficult to map).
Therefore the model might need some sort of reference points on the
ground to be matched to the building polygon.

Even if you don't look that deep, it should IMHO be possible to use the
same model for different buildings, thus rotation is a must.

Overall, it follows that the matching from osm building to 3d model
needs some way to define:
- which model (e.g. by model id)
- which orientation (nodes of the osm polygon/multipolygon to reference
nodes on the model

Even harder it's for street lamps, post boxes and stuff like that as
they are mapped as a node only, while the mapping might require an
orientation of the model.

regards
Peter

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

Re: [OSM-dev] [GSoC] Sharing models web application info

[Peter Wendorff]

bin5Czv7jEVTk.bin
Description: PGP/MIME version identification


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

Re: [OSM-dev] License for Javascript code [repeat]

[Peter Wendorff]

Hi,
As I indeed think OSM should be clear and as correct as possible, and as
I don't know if Richard will open that issue, I opened an Issue [1]
myself on github quoting his mail.

I fear I'm not able to decide about the license, so I don't want to
patch it in myself.

regards
Peter

[1] https://github.com/openstreetmap/openstreetmap-website/issues/879

Am 27.01.2015 um 10:20 schrieb Andy Allan:
> On 27 January 2015 at 03:44, Richard Stallman  wrote:
> 
>> The GPL says that this decision is made and stated with notices in the
>> source files, but these source files have no such notices, meaning no
>> decision was ever stated.
> 
> Thanks for bringing this to our attention, and you are correct that we
> haven't put license information in each of our files. I for one was
> unaware that there was this ambiguity, although I'm not a maintainer
> of the software, only an occasional committer.
> 
> Since this list is used for a wide range of openstreetmap-related
> development projects, not just the code for the website, here are some
> more targetted links:
> 
> http://git.openstreetmap.org/rails.git/
> https://trac.openstreetmap.org/query?status=new&status=assigned&status=reopened&component=website&order=priority
> https://github.com/openstreetmap/openstreetmap-website
> 
>> Can I ask the developers of those files to make a choice, so that it
>> can be listed in the source files and finish specifying how they are
>> licensed?
> 
> There are approximately 112 developers involved in the whole codebase,
> so I hope we won't need to contact each of them! For a number of years
> the README has stated:
> 
> "This software is licensed under the GNU General Public License 2.0.
> See included LICENSE file for details."
> 
> ... so I expect the answer is that it's v2 only, not v2 and later. In
> saying that, we could certainly be more clear in each of the source
> files in addition to the README
> 
> Thanks,
> Andy
> 
> ___
> 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] Moving to stricter multipolygon parsing

[Peter Wendorff]

IMHO, and that's what most bothers me at the old interpretation of
multipolygons, any tag that belongs to a closed way should be valid for
that closed way.
We don't inherit names from streets to bus route relations - why should
we do so for names of polygons to multipolygons?

Therefore my interpretation is, and IMHO it's the most intuitive
interpretation, that the multipolygon relation describes "it's own"
geometry, by referring to other objects (!) geometries, where these
other objects may be features on their own or not.
That means: Tags that are used on an outer closed way of a multipolygon
relation should hold for the area enclosed by that way.
Tags that are used on  an outer non-closed way of a multipolygon
relation should hold for that way, which is not closed and doesn't get
more closed by other ways somehow related to it by a multipolygon.

For inner member ways it's basically the same.

This should IMHO not be dependent on any kind of tags (besides the
area=yes for closed ways where the closedness is not clearly implied by
other tags).

regards
Peter

Am 13.06.2014 16:10, schrieb Martin Koppenhoefer:
> 2014-06-13 1:25 GMT+02:00 Paul Norman :
> 
>> I think we need to move to a more strict parsing of MPs, accepting only
>> new-style MPs and old-style MPs where all outers have identical
>> non-deleted[2]
>> tags and the relation itself has no non-deleted tags.
>>
> 
> 
> +1
> 
> There is really only one usecase where I abuse the fuzziness of the old
> style: urban squares. While you often can't walk on all of their surface
> (e.g. there might be a fountain, a sculpture, buildings, green, etc. to
> exclude from highway pedestrian) the name will usually be for all of it.
> Adding only a name also doesn't solve it, because then it is not clear
> which kind of name it is (typology). This isn't really solved with old
> style MPs neither, of course, but at least this is less obvious and might
> be interpreted correctly by a human ;-)
> 
> 
> 
> ___
> 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] Moving to stricter multipolygon parsing

[Peter Wendorff]

+10
if we could enforce the strict usage in multipolygon relations this
might as well be a step forward to a future area datatype as it would
straighten the definition of how areas are defined currently, and start
by a less ambiguous definition for the subset of areas described by
multipolygon relations.

regards
Peter

Am 13.06.2014 01:25, schrieb Paul Norman:
> Osm2pgsql currently tries *very* hard to turn multipolygon relations into
> geometries. It currently detects two types of MP relations, new-style and
> old-style. A new-style MP has tags on the relation while an old-style MP
> only has type=multipolygon on the relation and relies on the ways for
> the tags.
> 
> It then tries to deal with odd tagging in various ways. MP handling is one
> of the biggest sources of osm2pgsql bug reports[1] and a big time-sink.
> 
> One of the bigger issues is moving tags from ways to MPs that are falsely
> detected as old-style. This is an attempt to interpret flawed tagging.
> 
> I think we need to move to a more strict parsing of MPs, accepting only
> new-style MPs and old-style MPs where all outers have identical
> non-deleted[2]
> tags and the relation itself has no non-deleted tags.
> 
> Osm2pgsql is not just a consumer of data, it is one of the main feedback
> tools, so it is strongly integrated into the feedback cycle, so if
> osm2pgsql
> doesn't process a multipolygon, a mapper will likely correct the
> tagging. By
> doing this, it will make it easier for those interpreting raw OSM data.
> 
> To support this, I looked for some numbers. Using a shortened deleted tags
> list, there are 1 million new-style and 261k old-style MPs. Of the
> old-style,
> 256k have a member with role outer. 251k of these have entirely consistent
> tags on outers, while 2.3k have two sets of tags among the ways. About 180
> have three or more.[3] An old-style MP without entirely consistent tags on
> outers is ambiguous and in error.
> 
> [1]:
> https://github.com/openstreetmap/osm2pgsql/search?q=multipolygon&type=Issues
> 
> [2]: A deleted tag is one such as source that osm2pgsql is dropping
> [3]: https://gist.github.com/pnorman/ebd41f5a1759916a48b5
> 
> ___
> 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] new on osm

[Peter Wendorff]

Hi Sachin,
Overpass is usually faster and - if you need it - has more features.
Read the Overpass-API documentation for more details, or play around
with overpass-turbo (http://www.overpass-turbo.eu) which is a frontend
to overpass.

regards
Peter

Am 21.03.2014 16:20, schrieb Sachin Dole:
> Hello,
> 
> @Simone, would you suggest Overpass or XAPI for the second question asked
> by the OP? I am also a newbie and at this very moment I am trying out OSM
> Nominatim install on Amazon EC2. I previously was using Mapquest's open/OSM
> data, but that seems to be old and unmaintained! I would love to know why
> use overpass instead of XAPI for read only queries.
> 
> Thanks!
> Sachin Dole
> 
> 
> On Fri, Mar 21, 2014 at 10:12 AM, Simone Cortesi  wrote:
> 
>> On Fri, Mar 21, 2014 at 3:20 PM, Giuseppe Ricci 
>> wrote:
>>
>> Hi Giuseppe,
>>
>>> But I want to understand if osm's data permit to implement my idea.
>>> My first question is: if I have some points of interest and I want to
>> show
>>> these on an open street map is it possible? For example with google map
>>> there is this tutorial:
>>>
>>> https://developers.google.com/maps/articles/phpsqlajax_v3
>>
>> we normally use http://leafletjs.com/ as a front-end to osm tiles.
>>
>> the DB approach you suggest is still valid inside OSM, you need to
>> provide your own database and create a structure which can be queried
>> by your script, a that is able to provide well formatted json or csv
>> based on the requested bounding box. there are numerous plugins for
>> that: http://leafletjs.com/plugins.html
>>
>>> The second question is: can I query the osm's database to find hotels,
>>> restaurants, shopping center, etc? Is it possible to show these points
>> on a
>>> osm map?
>>
>> overpass API is the answer.
>>
>> shops in Bari: http://overpass-turbo.eu/s/2PS
>>
>> ___
>> 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

Re: [OSM-dev] Strange map div layout problem with OL 2.13 and Chrome only

[Peter Wendorff]

Hi Armin,
Don't have Chrome installed, but with Chromium (Version 32.0.1700.107
Ubuntu 12.04 (32.0.1700.107-0ubuntu0.12.04.1~20140204.866.1) I couldn't
reproduce the problem - both pages look identical and "correct".

regards
Peter

Am 22.02.2014 10:44, schrieb Armin:
> Hi,
> 
> I'm in the process of upgrading to OL 2.13. Everything seems to be fine
> with Firefox, but in Chrome, the map div exceeds the boundaries of the div
> it's put into, i.e. it blanks out other divs on the page.
> 
> This is the site with the old OL code:
> http://www.xctrails.org/map.html - here, the layout is consistent between
> FF and Chrome
> 
> This is the site with OL 2.13 included:
> http://www.xctrails.org/map213.html - broken layout on Chrome.
> 
> Any idea what could be going on there?
> 
> Thanks,
> Armin
> 
> 
> 
> ___
> 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] Unusual large Changesets - Could OSM server API split uploaded data in more then one changeset?

[Peter Wendorff]

Am 09.02.2014 15:33, schrieb Pierre Béland:
> Hi Peter,
> 
> Then  a warning could be given in editors such as JOSM highlighting such 
> edits that cover large zones.
Yes, that would be useful. Nevertheless it's nothing in the API, but in
the Editors.

regards
Peter
> 
> 
>  
> Pierre 
> 
> 
> 
> ____
>  De : Peter Wendorff 
> À : dev@openstreetmap.org 
> Envoyé le : Dimanche 9 février 2014 4h59
> Objet : Re: [OSM-dev] Unusual large Changesets - Could OSM server API split 
> uploaded data in more then one changeset?
>  
> 
> Hi Pierre,
> as far as I know: no, that's not possible.
> A changeset is not an atomic thing in OSM. It consists of a number of
> tags (most often source and changeset if any) and a number of osm object
> versions (nodes, ways and relations) and a bounding box.
> This bounding box afaik is a boundingbox containing all objects edited,
> but may be even larger.
> 
> Your propose the API to split this, but let's examine the following
> counter example:
> 
> You are really editing a large area, let's say, you check a big part of
> the coastline of a continent, let's say Europe.
> You loaded the coastline into the editor and then start working on
> fixing several gaps and bugs in it, going through a list of errors
> returned e.g. by some coastline-checker tool.
> 
> Let's say this list is not ordered along the coastline. Instead you fix
> the first error at the north sea coast of Latvia, then another one in
> Greece.
> After these two you decide to upload the first chunk of your changeset,
> but not to close it (which is possible!).
> 
> The changes are online and valid immediately, and therefore they have to
> have a changeset id they belong to. Thus at this point in time the API
> has to decide to split these two edits to two changesets or not.
> According to anything known up to know the changeset would be splitted,
> but in the following hours you fix hundrets of other errors in the
> coastline, and in the end every few kilometers there's an edit.
> Would you have done it in a different order, the API wouldn't have split
> the changeset at all, but now it's too late, many data consumers already
> have pulled the first edits of your changeset, stored them under the
> changeset ID the API decided at first.
> 
> Nevertheless I think you write about something which would indeed be
> very useful, and that is to split the visual bounding boxes of one
> changeset into several parts.
> 
> Currently each changeset is visualized as one big bounding box, but
> instead it would in fact be much more useful to e.g. visualize it as all
> affected tiles. Your changeset would then appear as two blobs of color,
> one small box in Mali and another one in Bolivia.
> 
> But that's not a problem of the API and of the Changeset Bounding box,
> but of the Visualization of Changesets and the algorithm pascal uses to
> calculate the activity area.
> It's the only simple way to get the activity area, as the bounding box
> is the only coordinate to get by changeset without inspecting every
> element inside, so it's a perfectly valid way to go, and it works most
> often.
> Inspecting further would require the API or the consuming application
> (eg. wdyc and Pascals contributor statistics) to do much more work, and
> it's the question if that's worth it.
> 
> regards
> Peter
> 
> 
> Am 08.02.2014 20:17, schrieb Pierre Béland:
>> See changeset where editing only in bottom left corner and upper
>> right corner http://www.openstreetmap.org/changeset/20447101
>>
>> The bbox of the changeset above is not very instructive of the zone
>> covered by this edit.  I updated one way in Mali. Then forgot to save
>> before I moved to Bolivia for other editing again in a small area.
>>
>> For example, if I look at contributor statistics for Bolivia with 
>> Pascal Neis new Contributor statistics by a specific comment, I see a
>>   small box for Bolivia, and a large box covering two continents,
>> simply due to this single changeset. 
>> http://resultmaps.neis-one.org/osm-changesets?comment=hotosm-bolivia
>>
>> Such large bbox create problems when we want to analyse Contributor
>> activities in one area extracting Changesets for a particular bbox.
>> It is also difficult to assure follow-up of activities in a local
>> zone you take care of.
>>
>> To correct this problem, could the OSM API that take care to upload
>> data to the OSM database analyze such Changesets that cover a large
>> zone, in particular more then one continent, and split them if
>> necessary in more the

Re: [OSM-dev] Unusual large Changesets - Could OSM server API split uploaded data in more then one changeset?

[Peter Wendorff]

Hi Pierre,
as far as I know: no, that's not possible.
A changeset is not an atomic thing in OSM. It consists of a number of
tags (most often source and changeset if any) and a number of osm object
versions (nodes, ways and relations) and a bounding box.
This bounding box afaik is a boundingbox containing all objects edited,
but may be even larger.

Your propose the API to split this, but let's examine the following
counter example:

You are really editing a large area, let's say, you check a big part of
the coastline of a continent, let's say Europe.
You loaded the coastline into the editor and then start working on
fixing several gaps and bugs in it, going through a list of errors
returned e.g. by some coastline-checker tool.

Let's say this list is not ordered along the coastline. Instead you fix
the first error at the north sea coast of Latvia, then another one in
Greece.
After these two you decide to upload the first chunk of your changeset,
but not to close it (which is possible!).

The changes are online and valid immediately, and therefore they have to
have a changeset id they belong to. Thus at this point in time the API
has to decide to split these two edits to two changesets or not.
According to anything known up to know the changeset would be splitted,
but in the following hours you fix hundrets of other errors in the
coastline, and in the end every few kilometers there's an edit.
Would you have done it in a different order, the API wouldn't have split
the changeset at all, but now it's too late, many data consumers already
have pulled the first edits of your changeset, stored them under the
changeset ID the API decided at first.

Nevertheless I think you write about something which would indeed be
very useful, and that is to split the visual bounding boxes of one
changeset into several parts.

Currently each changeset is visualized as one big bounding box, but
instead it would in fact be much more useful to e.g. visualize it as all
affected tiles. Your changeset would then appear as two blobs of color,
one small box in Mali and another one in Bolivia.

But that's not a problem of the API and of the Changeset Bounding box,
but of the Visualization of Changesets and the algorithm pascal uses to
calculate the activity area.
It's the only simple way to get the activity area, as the bounding box
is the only coordinate to get by changeset without inspecting every
element inside, so it's a perfectly valid way to go, and it works most
often.
Inspecting further would require the API or the consuming application
(eg. wdyc and Pascals contributor statistics) to do much more work, and
it's the question if that's worth it.

regards
Peter

Am 08.02.2014 20:17, schrieb Pierre Béland:
> See changeset where editing only in bottom left corner and upper
> right corner http://www.openstreetmap.org/changeset/20447101
> 
> The bbox of the changeset above is not very instructive of the zone
> covered by this edit.  I updated one way in Mali. Then forgot to save
> before I moved to Bolivia for other editing again in a small area.
> 
> For example, if I look at contributor statistics for Bolivia with 
> Pascal Neis new Contributor statistics by a specific comment, I see a
>  small box for Bolivia, and a large box covering two continents,
> simply due to this single changeset. 
> http://resultmaps.neis-one.org/osm-changesets?comment=hotosm-bolivia
> 
> Such large bbox create problems when we want to analyse Contributor
> activities in one area extracting Changesets for a particular bbox.
> It is also difficult to assure follow-up of activities in a local
> zone you take care of.
> 
> To correct this problem, could the OSM API that take care to upload
> data to the OSM database analyze such Changesets that cover a large
> zone, in particular more then one continent, and split them if
> necessary in more then one changeset?
> 
> 
> 
> 
> 
> 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

Re: [OSM-dev] Two technology related questions

[Peter Wendorff]

Hi Sandor,
I'll try to answer your questions between your original post.

Am 30.01.2014 11:23, schrieb Sandor Seres:
> I am not sure am I in the right forum to ask the two tiling related
> questions here. If not, I do hope someone could redirect me to the right
> place/forum. 
> 
> As I understand the OSM raster-tiles serving system is one of the
> fundamental OSM services. Even the front page map (the SlippyMap and its
> layers) is based on this service as well as many private mapping systems.
> Further I understand that these tiles are pre-generated, edge aligned colour
> raster images in PNG format of a uniform dimension and created per zoom
> levels. At the same time, the OSM source data is (implicitly and apart from
> the attributes) in a vector format. 
That's correct
> So, at some stage the mentioned service
> must perform a vector-to-raster transformation and here is my first
> dilemma/question:
The software doing that transformation in case of the tiles shown on
osm.org is called Mapnik, see www.mapnik.org
> 
> 1. Are you rasterizing geometry/vector objects first for a larger area and
> then tiling this raster image, or the contrary? First tiling the
> geometry/vector objects and so rasterizing these vector tiles?
Something like that.
Mapnik usually is configured to render a block of e.g. 5x5 tiles as one
big image, the so called meta-tile and slices the result down to
individual tiles.
To avoid clipping effects neigbouring meta-tiles overlap and the
overlapping parts are ignored.

On the other hand the vector data is kind of tiled too by using
appropriate database indices and - initially - storing the vector data
in a projection which is suitable to easily clip to the area of interest.

> Next, I think I understand how the maintenance of this raster tiles database
> happens. When a mapper uploads a change all related tiles are marked for
> re-rendering.
Yes, but to make sure you understand: There are two databases and one
set of files involved:
The Mapper uploads to the api-database.
A process produces updates of that api-database in minutely chunk files
(so approximately once a minute there's a new osm-change-file)
At the rendering server a second process fetches the osm-change-files
and parses it. While parsing it does:
- the projection (as I wrote above) suitable for rendering
- insert/update/delete each object into the database
- mark affected tiles as dirty for each changed/inserted/deleted object.

> So, at an appropriate time the marked tiles are re-rendered
> and the users have an impression (more or less) that the updates happen
> on-the-fly. 
Basically yes. Mapnik runs as a service with a rendering queue (or
better more than one rendering queue). Tiles not marked as dirty don't
have to be rerendered and are sent to the mappers client on request.

Dirty tiles are rerendered depending on their zoomlevel. The
low-zoom-levels (z0..5 afair) are rendered usually independent of tile
requests as they use a lot of data for the same image size and therefore
rendering takes too much time (and of course they would be dirty very
often as they span across a big area of the world).

Higher zoom levels may be rendered in a render queue too if there's
spare time, but may be rendered with higher priority on demand, too.

I could not find some more details about this marking process.
> So, my second dilemma/question is:
> 
> 2. When an object (given by a relation) has changed, do you mark all the
> related/coverage tiles for re-rendering or only those affected by the
> change?
As far as I know all related/covereage tiles are marked as dirty, but
the low zoom levels are not rerendered on request. So if I am up to date
there is no decision based on attributes (e.g. zoom level 2 is not
affected because there's only a highway-tag which changed and highways
aren't shown on z2).

> Just to be a bit more precise regarding the second question. Assume we have
> an area object, for example a larger lake with islands, given by a relation.
> Assume, a local editor will refine the object by changing just a short
> section of the outer polygon, or/and just to insert a new small missing
> island. The whole object is covered by hundreds of tiles while the actual
> change is covered by only a few.
It's rerendered completely as the whole lake is in the database as one
object, independent of the internal structure of osm objects it is
derived from.

regards
Peter

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

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Peter Wendorff]

Hi Pieren,
If that's the case, then the european centric stuff should go to an
extra page, but what you referred to with the africa page [1] IMHO
perfectly fits into a global definition. Probably for some countries the
last short paragraph may be not that relevant, but that doesn't turn it
to be wrong.

That page looks like a good entrypoint to the highway classification
itself. In contrast, [2] is not only european centric, but
British-Centric, often referring to the UK road classification system,
but not providing a common sense for worldwide use.

What's missing isn't a page for African highways in particular, but for
the international meaning of the highway tag, independent of the UK road
classification system (like in [2]) or the German one (like in [3]).

As especially English as a language is used in many countries of the
world, it's dangerous, that there is still no way to differentiate
between "English", "American" and "international, written in English" or
something like that.

In fact we should have wiki pages for languages and countries distinct
from each other; something like

highway:DE (highway-tag and it's usage in Germany, e.g. mapping to
traffic signs, specific samples etc.)
highway:de (the Highway-Tag as used internationally, but written in German)
highway:DE:de (the highway-tag as used in Germany, written in German)
highway:UK:en (the highway-tag as used in the UK, written in English)
highway:UK:de (the highway-tag as used in the UK, written in German)

But at least I think we should have something like
Key:highway => international (!) variant
en:Key:highway => English variant (which may vary from the international
variant as well as the German variant may vary - if possible it
shouldn't in the definition, but there may be country/language specific
details for English-speaking countries.

regards
Peter

[1] https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa
[2] http://wiki.openstreetmap.org/wiki/Key:highway
[3] http://wiki.openstreetmap.org/wiki/DE:Key:highway


Am 08.01.2014 13:40, schrieb Pieren:
> On Wed, Jan 8, 2014 at 1:30 PM, Martin Koppenhoefer
> 
>> My suggestion is to delete the page or link to the
>> specific pages in to keep the wiki maintainable. Duplicating the same
>> information over and over again has no sense and raises the risk for
>> inconsistencies.
> 
> +1 to remove duplicates.
> However, I see some interest to have a specific documentation for
> Africa. The highway main doc is very european centric. But this
> discussion should continue on the tagging list.
> 
> 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] Assembling imagery: to mosaic or not

[Peter Wendorff]

Hi Paul,
IMHO for osm editing purposes multiple distinct sources are better.
The first reason is to give a proper source tag, the second one to check
for updates only where necessary when one source imagery set changes.
On top of that continuity breaks in the imagery IMHO it should be clear
for the mapper that this is due to different image sets, image dates and
so on.

regards
Peter
(mapping from imagery sometimes but not hosting any)

Am 03.01.2014 23:19, schrieb Paul Norman:
> I host various sources of imagery for the benefit of local users. One 
> fairly typical scenario is where I have two sources of imagery covering 
> an area. Although I create layers for each source, I'm not sure what to 
> best put as a source for the list in the editors. The two options are to 
> add a number of discrete sources, or to add a layer mosaicking them 
> together, and displaying what the best source is at any one point. 
> 
> One mosaic
> - Does not requires users to switch between layers at edges
> - Technically more difficult to implement
> - More fine-grained control over what layer is default when all the 
>   sources are better than Bing, but doesn't work as well when some 
>   sources are better and others are worse
> 
> Multiple sources
> - Requires users to load up more imagery sources to view the area, and 
>   when coverage overlaps to load the sources in the right order so the 
>   better sources appear on top
> - Requires no additional work to implement
> - Setting what layer is default does not work well for overlapping 
>   sources where both sources are better than Bing
> 
> I'd like the thoughts of others, particularly those who host imagery for 
> editors where they have overlapping sources 
> 
> I am currently leaning towards setting up a mosaic of the 8-12 sources. 
> These include:
>   
> - Latest available Landsat8 (~3-6 months old, given BC clouds), 15m/px
> - 2013 Surrey imagery, 10cm/px
> - 2010 Surrey imagery (covers some blanks in 2013), 10cm/px
> - 2012 Vancouver imagery, 10cm/px
> - 2012 Kelowna imagery, 10cm/px
> - 2012 Nanaimo imagery, 10cm/px   
> - 2009 Nanaimo imagery, 30cm/px
> - 2009 DataBC GVRD West imagery, 10cm/px
> - 2009 DataBC GVRD East imagery, 20cm/px
> 
> 
> ___
> 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] wrong redering of tunnels on the main site after the change of rendering rules

[Peter Wendorff]

Am 15.10.2013 07:54, schrieb Maarten Deen:
> On 2013-10-15 04:51, Michael Kugelmann wrote:
>> On 14.10.2013 10:52, Maarten Deen wrote:
>> On 2013-10-14 10:34, Michael Kugelmann wrote:
>> Hello,
>>
>> while the weekend I stumbled accross the old Elbe tunnel at Hamburg
>> https://de.wikipedia.org/wiki/St._Pauli-Elbtunnel
>> https://en.wikipedia.org/wiki/Elbe_Tunnel_%281911%29
>> and how it is rendered on the main OSM site (mapnik style):
>> http://www.openstreetmap.org/?mlat=53.5439&mlon=9.9665#map=16/53.5439/9.9665
>> It looks like a road going above the water...   :-(
>>
>> For me the tagging seems to be all right (level, tunnel, etc, all is
>> set) but maybe that the new rendering rules are not correct when the
>> tunnel is below water? Could someone please investigate? Thanks.
>>
>> What do you expect to see? That the tunnel is not rendered when it is
>> below a waterbody? Usually tunnels only have a very blurred/bright color.
>> Please have a look to a normal tunnel like eg. the Engelbergtunnel:
>> http://www.openstreetmap.org/?mlat=48.7933&mlon=9.0237#map=15/48.7933/9.0237
>>
>> https://de.wikipedia.org/wiki/Engelbergtunnel
>> https://en.wikipedia.org/wiki/Engelberg_Tunnel
>> There the tunnel can hardle be seen on the rendering.
>> In the case of the Elbe Tunnel (under water) the road has the same (or
>> almost the same) color as it would be "above the water". For me this
>> really confuses.
>>
>> That has never been the case. Tunnels under water have always been
>> rendered the same way they look when under a landmass: lighter in
>> color and dashed lines.
>> Please compare Engelbergtunnel (landmass) to Elbe-Tunnel. This can't
>> be the same. Maybe the additional access control flags on the Elbe
>> Tunnel cause the problem, I don't know.
>>
>> Compare the Zeeburgertunnel in Amsterdam (natural=coastline):
>> 
>> Or the Gouwe-Aquaduct (natural=water)
>> 
>> both are fine but could be even a litte more bright (IMHO).
>> But if you compare these two against the Elbe-Tunnel you can see that
>> the Elbe tunnel is not at all that bright and "hidden".
> 
> If you look closely, you'll see that the colors do differ and that the
> line at the edge is dashed. It is probably because it is a tertiary road
> which is rendered in light yellow that the difference is small.
> Normal tertiary road is rendered in #F8F8BA, as a tunnel it is #F9F9D0.
> The difference is small, but it is present. Maybe the difference in
> color could be greater, but that's the only issue that exisits. It is
> rendered differently.

Nevertheless it LOOKS the same - or at least VERY similar. Being
rendered differently doesn't matter, I think, as you have to look twice
(if that's enough) to see it's a tunnel.
One issue here are the very similar colors (as you said), the other one
IMHO is the dotted tunnle casing (under water) which is nearly invisible
against the water body. This leads to the tunnel looking like a usual
street as ONLY the color differs VERY SLIGHTLY.

regards
Peter

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

Re: [OSM-dev] Standard for Map Key

[Peter Wendorff]

Hi Andy,
I know that it's not easy - and I'm sure it's not possible to do
completely without manual work, but I think, it would be great to have
something like that.

Let's see, what a feature in a map key usually is.

1) a label in the users language describing the features meaning (e.g.
city, capital, ...)
2) a small graphical image showing how that feature looks like.

The Problem Andy pointed out is, that there is nothing like "a feature"
in the Map Style languages we have so far.
Mapnik simply uses the painters algorithm to draw parts of the map on
top of each other, building a feature out of several individual parts
(like: highway casing, highway fill, highway marker (e.g. oneway),
highway label halo, highway label).

MapCSS and CartoCSS tackle this slightly introducing special features to
connect these parts together. Style developers don't have to use these,
but it's possible.
Here we now have something like "a highway with this casing, that fill
and a label like that".

Nevertheless this must not be connected completely.
E.g. a tunnel might "inherit" the highways attributes, as in the
background it's still mapniks painter algorithm processing the map data.

But what's necessary to build a map key item?

- we have to know what should be in this map key
- we have to know if that map key should be displayed.

For Mapnik we could use an additional attribute to any symbolizer.
Let's call it mapkey, and let it work semantically like the class
attribute in html, containing a list of class names.

>From that we could generate a map key:
- for each "mapkey" value (where one mapkey attribute is a list of
values) get all items sharing the same map key.
- generate a data item for that:
  - from the symbolizer types decide if you use a rectangle, line or
point as a basis
  - add the features to match filters and label-attributes
  - render as usual with the mapnik style

This could be tweaked, e.g. rendering on different background colors or
whatever, but it's essentially what I would expect in the map key.

Now only the label texts (describing the individual features) are
missing, but you could use the "class" names for this as a key in any
localization engine like on osm.org.

Your https://github.com/gravitystorm/mapnik-legendary approach IMHO is
exactly the right direction, it's just one additional step to add it to
the stylesheets instead of adding an additional file.

For your example file [1], as far as I understand it:
- width height and background are general settings for the map key.
- features is a set of features to add to the map key - with my sketched
idea above these would be the individual mapkey "classes" from cartocss.
- type: as described: depends on the symbolizers used on the current class
- tags: as described: pulled from filters and labelling-commands
- layers: might not be necessary
- zoom: should be a zoom range and could be pulled from the zoom
selectors of the layers.

I'm sure it's possible to bundle that together, and even bundling that
to cartocss should be possible - and might be interesting for tilemill
as well.

regards
Peter

[1]
https://github.com/gravitystorm/mapnik-legendary/blob/master/examples/openstreetmap-carto-legend.json


Am 16.09.2013 14:53, schrieb Andy Allan:
> On 16 September 2013 12:14, Peter Wendorff  wrote:
> 
>> as far as I know all map keys are created by hand.
> 
> I think that's true, and therefore somewhat tedious!
> 
>> 2) it would be really great to have some automatic map key generation
>> out of the style files. For Mapnik that's incredible ugly as mapnik does
>> not have any semantic connection between e.g. highway casing, fill and
>> label. For CartoCSS (which is used since a while for the default style)
>> this might be possible in parts.
> 
> I don't think it's particularly feasible - the definitions for all the
> symbolizers that make up a zoom level 17 trunk bridge are spread
> around a fair amount, and so you'd need a "CartoCSS-complete" parser
> to figure out what symbolizers apply to a feature, and then a
> "mapnik-complete" rendering engine to ensure that the symbolizer
> attributes are accurately reflected in the legend images. Which is
> why...
> 
>> In any case it would require additional information like which label to
>> use for a particular feature in the map key, which items should NOT be
>> displayed (as Tom mentioned) or in which order items should be displayed.
> 
> ... I've been developing something that does this. It takes a
> legend.json file which describes what features should be drawn (and in
> what order, what description to use, which geometries etc) and spits
> out a series of mapnik renderings for each feature. It's still very,
> 

Re: [OSM-dev] Standard for Map Key

[Peter Wendorff]

Hi,
as far as I know all map keys are created by hand.
I'm not sure what you refer to exactly, but basically I see two things
which would be great to have:

1) some kind of "standard" to retrieve a map key for a given tile set;
e.g. tile-URL is tile.openstreetmap.org/{z}/{x}/{y}.png, then search for
map key information (in a structured format, not html) at
tile.openstreetmap.org/mapkey.xml
As far as I know there is nothing like that yet.

2) it would be really great to have some automatic map key generation
out of the style files. For Mapnik that's incredible ugly as mapnik does
not have any semantic connection between e.g. highway casing, fill and
label. For CartoCSS (which is used since a while for the default style)
this might be possible in parts.
In any case it would require additional information like which label to
use for a particular feature in the map key, which items should NOT be
displayed (as Tom mentioned) or in which order items should be displayed.

regards
Peter


Am 16.09.2013 11:55, schrieb Peter K:
> Hi,
> 
> is there a kind of a standard or suggestion on how to retrieve the map
> key? Like an http API or a leaflet plugin? On osm.org there is only the
> 'map key' data available for the default layer in the right box. And not
> all details are given like here:
> http://wiki.openstreetmap.org/wiki/DE:Map_Features
> 
> Someone knows some open source effort for more details and for support
> of the various providers like mapquest, osm.de, cloudmade, ...?
> 
> Kind Regards,
> Peter.
> 
> ___
> 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] Please readd "OSM" as export format

[Peter Wendorff]

Hi Manuel,
it's in the left column now, in the "Data" Section as "Export Data".

regards
Peter

Am 09.08.2013 08:48, schrieb Manuel Reimer:
> Hello,
> 
> I really like the new website layout.
> 
> But for some programs OSM files as input are very handy and the new "Export"
> feature no longer has this format in the dropdown list.
> 
> Can this be added to the new interface, again?
> 
> Thanks
> 
> Yours
> 
> Manuel
> 
> 
> ___
> 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] The new link on the OSM map

[Peter Wendorff]

Hi.
The ticket was there already, I added a patch now:
http://josm.openstreetmap.de/ticket/8945

regards
Peter

Am 08.08.2013 09:08, schrieb Maarten Deen:
> Very nice that the main map now shows a link as standard, but why does
> the format have to be changed? Now JOSM needs to be changed because it
> does not recognise this type of link.
> What was wrong with the old lat= and lon= style? From this link I can
> not see what the latitude and longitude is. I have to know in which
> order it is.
> 
> I'm sorry, but IMHO this is yet another step backward.
> 
> Maarten
> 
> ___
> 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] The new link on the OSM map

[Peter Wendorff]

+1
I think, it's easy to exchange in josm.
The bigger problem here would be the big amount of links TO osm.org, bu
these are already addressed by the current page and redirected to the
new format, so that's no problem either.

I hope it was an accident that you responded to my mail instead of
responding to Maarten, as I totally agree and welcome the change (with
of course the few and small drawbacks of changing behaviour, that has to
be tackled, but it will, and I didn't complain about that).

regards
Peter

Am 08.08.2013 14:49, schrieb Tom MacWright:
> Is it really a terrible weight to update JOSM to recognize the new format?
> Given that JOSM is on version 6,115 and this is essentially a 'changing a
> regex' type situation.
> 
> Can we stop calling any feature that changes the behavior of the site "a
> major step backwards"? Yes, things are different and possibly some use case
> you had is different or harder, but realize on the other side this is (1)
> generally a beneficial change and (2) the result of a volunteer already
> slogging through tens or hundreds of comments on a GitHub queue and finally
> getting it through. And, finally, it's merged... and the first thing we
> hear is negative criticism about a corner case that says "you did a bad
> thing entirely". This is why nobody wants to code on openstreetmap-website.
> 
> 
> On Thu, Aug 8, 2013 at 3:36 AM, Peter Wendorff 
> wrote:
> 
>> Hi Maarten,
>> the benefit with the new link format, where position and layers are
>> constantly stored in the part after the hash (#) is that browsers don't
>> need or assume to need a reload.
>> If you change the address (before the #) completely, a reload of the
>> page is necessary, that was the case up to the change.
>> Now it's not necessary to reload the page to get the correct link in the
>> address bar.
>> What you complain is of course an argument straight in the opposite
>> direction, but both ways are perfectly valid.
>> You are in fact right that it's not possible any more to determine from
>> the link which part of the coordinate is latitude and which is
>> longitude, but it's consistently the same any time, so that's not that
>> big problem either.
>> Probably the hash format could better be extended by lat/lon to be
>> something like #z=15/lat=51.2/lon=8.7
>>
>> Your complaint about reloading the page to get the initial view back is
>> IMHO an unusual one as it assumes that you go to the page with a direct
>> link to a defined position; something which is possible with osm.org,
>> but something nobody cared about in the last days probably.
>> For this wish I don't have a solution combining your demand with the
>> benefits of the new hash-format, but probably even there is a solution
>> possible.
>>
>> regards
>> Peter
>>
>> Am 08.08.2013 09:16, schrieb Maarten Deen:
>>> On 2013-08-08 09:08, Maarten Deen wrote:
>>>> Very nice that the main map now shows a link as standard, but why does
>>>> the format have to be changed? Now JOSM needs to be changed because it
>>>> does not recognise this type of link.
>>>> What was wrong with the old lat= and lon= style? From this link I can
>>>> not see what the latitude and longitude is. I have to know in which
>>>> order it is.
>>>>
>>>> I'm sorry, but IMHO this is yet another step backward.
>>>
>>> Added complaint: before, I could zoom in, move the map, do whatever I
>>> wanted and then reload the screen and I got the initial view back. Now
>>> the map link changes when you zoom or move the map, making it difficult
>>> to get the initial view back. You have to remember to copy the link and
>>> than paste it back again otherwise you will never get the initial view.
>>> Please get the old style link and working back. The fact that there is
>>> no direct visible link to the map is now the least of the problems.
>>>
>>> Regards,
>>> Maarten
>>>
>>>
>>> ___
>>> 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] The new link on the OSM map

[Peter Wendorff]

Hi Maarten,
the benefit with the new link format, where position and layers are
constantly stored in the part after the hash (#) is that browsers don't
need or assume to need a reload.
If you change the address (before the #) completely, a reload of the
page is necessary, that was the case up to the change.
Now it's not necessary to reload the page to get the correct link in the
address bar.
What you complain is of course an argument straight in the opposite
direction, but both ways are perfectly valid.
You are in fact right that it's not possible any more to determine from
the link which part of the coordinate is latitude and which is
longitude, but it's consistently the same any time, so that's not that
big problem either.
Probably the hash format could better be extended by lat/lon to be
something like #z=15/lat=51.2/lon=8.7

Your complaint about reloading the page to get the initial view back is
IMHO an unusual one as it assumes that you go to the page with a direct
link to a defined position; something which is possible with osm.org,
but something nobody cared about in the last days probably.
For this wish I don't have a solution combining your demand with the
benefits of the new hash-format, but probably even there is a solution
possible.

regards
Peter

Am 08.08.2013 09:16, schrieb Maarten Deen:
> On 2013-08-08 09:08, Maarten Deen wrote:
>> Very nice that the main map now shows a link as standard, but why does
>> the format have to be changed? Now JOSM needs to be changed because it
>> does not recognise this type of link.
>> What was wrong with the old lat= and lon= style? From this link I can
>> not see what the latitude and longitude is. I have to know in which
>> order it is.
>>
>> I'm sorry, but IMHO this is yet another step backward.
> 
> Added complaint: before, I could zoom in, move the map, do whatever I
> wanted and then reload the screen and I got the initial view back. Now
> the map link changes when you zoom or move the map, making it difficult
> to get the initial view back. You have to remember to copy the link and
> than paste it back again otherwise you will never get the initial view.
> Please get the old style link and working back. The fact that there is
> no direct visible link to the map is now the least of the problems.
> 
> Regards,
> Maarten
> 
> 
> ___
> 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] Contributing GWT map widget

[Peter Wendorff]

Hi Alexander.

As you ask for the licensing restrictions: From OSM (as the map
(database) project) you are free to use whatever license you want on
your code.
OSM only restricts you in licensing of the data (not code using that
data) and tiles (rendered by the osm project based on this data).

Probably there is more restrictions for the license dependant on what
you mean with "contribute to OSM", e.g. if you want to add it to a
specific code repository or something like that; but as IMHO currently
git is rising, you may host your code on any repository you like, so it
doesn't matter necessarily what anybody thinks about restrictions on
"official" repostitories.
But of course: the more free your license is, the more people may have
reasons to use the widget.

regards
Peter

Am 12.07.2013 01:20, schrieb Alexander Maryanovsky:
> Hello,
> 
> I'm thinking of contributing my GWT map widget implementation (
> http://www.maryanovsky.com/sasha/maps/) to OSM.
> 
> What would be an acceptable license? Does it have to be the Apache License
> or can I go with LGPL?
> 
> 
> Thanks,
> Alexander Maryanovsky.
> 
> 
> 
> ___
> 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] Size of tiles

[Peter Wendorff]

Am 01.07.2013 23:23, schrieb Eric Fischer:
> At the equator, the length of a tile is the circumference of the earth
> (40,075 km) divided by 2^zoom, so a zoom level 19 tile is 76.4 meters on a
> side, for 5837m^2.
...but at the north pole (where we usually don't render), the north edge
of a tile represents 0 (the circumference of a point) divided by 2^zoom
= 0, so there's no general answer to your question.

regards
Peter
> 
> Eric
> 
> On Mon, Jul 1, 2013 at 2:16 PM, Vince Berubey  wrote:
> 
>> Hi,
>> using Mapnik and the python scripts, I generated tiles from zoom level 0
>> to 20. I was curious to find what is the exact size covered by a tile for
>> every zoom level.
>>
>> .i.e: Zoom19= 20m^2
>>
>> Best regards.
>>
>> ___
>> 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] adding fonts to OSM

[Peter Wendorff]

Am 21.06.2013 07:03, schrieb Gurpinder Chahal:
> 
> Thank You for repliyng.
> Do you mean I need to generate tiles again to change my fonts?
> Because clearing cache files will delete my tiles.
Of course you have to!
Tiles are graphic files, there's no font type inside any more, but a
bunch of pixels usually; so if you change your fonts to get different
looking tiles of course you have to re-render them.
If you do that by deleting all tiles and render everything from scratch,
or by marking all tiles dirty for mod_tile to request re-rendering on
demand, that's another question, but to get your new font's re-rendering
is definitively necessary.

regards
Peter

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

Re: [OSM-dev] Tile server

[Peter Wendorff]

Am 21.06.2013 06:13, schrieb Kaur gill:
> Thank you for your help.
> 
> Yesterday I was able to set the exact path for accessing the tiles.
> With that I got very small image of my map. When I tried to zoom it
> out, it disappears and again shows the pink square boxes.
> Is it the problem of tiles or something else?
Did you try again later (at least some minutes) to view the same area?
Is it still not showing tiles then?

Depending on your systems specs it may take really long to render a
tile, and if you didn't prerender anything, especially low-zoom tiles
may take longer than a HTTP Request will wait, so your browser get's a
timeout error and shows these pink squares therefore.

But:
1) you should see the corresponding render request be enqueued to the
mod_tiles render queue, and
2) if you come back later the tiles should be shown, as now the
corresponding meta tiles should be cashed on your disk.

regards
Peter

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

Re: [OSM-dev] About the geographic data in a .osm file

[Peter Wendorff]

Just to avoid confusions: The Geofabrik extracts does not cut along the
borders exactly, too.
They should be better (I guess), but not exact.
Exact splitting is much more expensive in terms of time and memory than
splitting a rough bounding polygon. That polygon should contain the
whole country, but may contain additional areas to reduce complexity.

And - of course: As far as I know none of the available extract services
splits ways or areas (except multipolygons probably) when exporting, so
if a way crosses the border, it's usually contained completely in the
extract.

regards
Peter

Am 24.05.2013 23:16, schrieb Vince Berubey:
> Thanks Toby,you answered exactly what I was trying to understand.
> - I do understand why i'm getting blank tiles.- I wanted to know why there is 
> data outside of delaware.
> I do understand know.
> 
> Date: Fri, 24 May 2013 16:12:33 -0500
> Subject: Re: [OSM-dev] About the geographic data in a .osm file
> From: toby.mur...@gmail.com
> To: scream...@hotmail.com
> CC: dev@openstreetmap.org
> 
> 
> First of all, did you notice that the cloudmade extracts are over a year old? 
> I would suggest looking at geofabrik for up to date 
> extracts:http://download.geofabrik.de/north-america.html
> 
> As for your tiles quesion, I'm not quite sure what you mean. Are you asking 
> why there is any data outside of Delaware? Or why you are getting blank tiles 
> where you don't have any data?
> 
> The cloudmade extracts never were too accurate on the state borders. When I 
> first downloaded Kansas they were missing the north border by a couple of 
> miles and had extra on the south. So it doesn't surprise me that the 
> cloudmade extract has extra data in it.
> 
> As for tile generation, the tile rendering process doesn't care about where 
> you do/don't have data. It just renders the tiles you tell it to render. If 
> there happens to be no data in that area then the tile will be blank.
> 
> Toby
> 
> 
> On Fri, May 24, 2013 at 3:08 PM, Vince Berubey  wrote:
> 
> 
> 
> 
> I have downloaded "delaware.osm.bz2 " 
> http://downloads.cloudmade.com/americas/northern_america/united_states/delaware#downloads_breadcrumbs
> 
> The boundary box I used when I generated my tiles from Generated_tyles.py  
> were a little bit bigger than the Delaware region.
> What I don't understand is why I was able to generate tiles that were in my 
> boundary box, but outside the Delaware area.
> 
> So, the .osm file does not exactly contain only the geographic data from the 
> region that you have downladed?
> Please look at this file, the red marks are the Delaware borders. I have a 
> lot of tiles generated outside of these borders:
> 
> http://postimg.org/image/ogwbjz5ln/
> Thank you for any explanation about it.
> Best regards.
> 
> 
> 
> ___
> 
> 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] lua+osm2pgsql=?

[Peter Wendorff]

Hi Kai.

I'm not sure, but as far as I understand you didn't say anything about
the use case of dropping tags from a relation to members.

Let's say motorway A44 is tagged as a relation and the individual ways
don't carry the ref-tag (ref=A44).
A common use case IMHO is to drop the tags down to the ways for
rendering, because that's far more easy than to draw highway shields out
of the relations attributes.

Is that possible in your lua implementation, too?

regards
Peter

Am 09.05.2013 23:02, schrieb Kai Krueger:
> Hello everyone,
> 
> In response to the previous thread, I have cleaned up the initial proof of
> concept patch, expanded it somewhat and I have now committed it into trunk
> of osm2pgsql.
> 
> As mentioned before, this allows to filter and transform (sets of) tags on
> nodes, ways and relations before continuing processing in osm2pgsql.
> Hopefully this can be used for a variety of things, like normalising
> tagging, or more sophisticated relation processing.
> 
> By default it still uses the old tag processing pipeline, but using the
> command line switch --tag-transform-script /path/to/tagprocessing_script.lua
> should enable the new more flexible pathway. At the moment it only works in
> the rendering output, but it shouldn't be too difficult to extend it to the
> gazetteer output if needed / wished.
> 
> The lua script you pass into osm2pgsql needs to implement 4 functions
> 
> function filter_tags_node
> function filter_tags_way
> function filter_basic_tags_rel
> function filter_tags_relation_member
> 
> The first three each take a set of tags as a lua key-value table and return
> a transformed (or unchanged) set of tags back. They also return a flag to
> say if the entity(way/node/relation) should be filtered out and not added to
> the database (they will still end up in the slim mode tables, but not in the
> rendering tables). The filter_tags_way function furthermore returns a flag
> if the way should be treated as a line or as a polygon.
> 
> The function filter_tags_relation_member is a bit more complex and allows to
> deal with more advanced relation tagging, such as multi-polygons that take
> can take their tags from the member ways.
> 
> This function therefore takes the set of tags from the relation, as well as
> the set of tags and role for each of the member ways (member relations and
> nodes get ignored). It then returns a transformed (and combined) set of tags
> to be applied to the relation in later processing. It furthermore returns a
> couple of additional information. First of all, one can specify for each
> member way, if it has already been dealt with, or needs to (potentially)
> have its own entry. E.g. outer ways in multi-polygon relations are
> superseded by the multi-polygon geometry. Tagged inner ways on the other
> hand still need to be processed as separate entries. Secondly, one can
> specify if the relation should be processed as a line, a polygon, or both
> (e.g. administrative boundaries). Thirdly, one can again specify to discard
> the entity from further processing.
> 
> There is a sample tag transform lua script in the repository as an example,
> which (nearly) replicates current processing and can hopefully be used as a
> template for ones own scripts.
> 
> Performance wise, the lua tag transform is slower than the C based one,
> however, it is probably not as bad as I feared. I haven't done an extensive
> performance analysis yet though and it will likely heavily depend on the
> complexity of the tag transform script.
> 
> Everything should hopefully work, but as with any new feature and
> particularly as I don't have a immediate use case for it myself, there is a
> non negligible chance that there are bugs in the committed code, so treat it
> with caution to begin with. As to support this a fair amount of refactoring
> was necessary, there is also a possibility that the default c-based tag
> transform got new bugs as well. I don't have the resources to test it on a
> full planet import, but on all of my test extracts, the non lua code
> produced the same database as before the commit. So hopefully things are OK.
> 
> For production systems, you should stick with the tagged 0.82.0 version of
> osm2pgsql. But I would very much appreciate any feedback on the new lua
> tag-transform possibilities.
> 
> Kai
> 
> 
> 
> 
> 
> 
> Kai Krueger wrote
>> In response to Richard's suggestion, I hacked up a proof of concept
>> implementation of a tag filter in lua last week.
>>
>> Currently it allows you to write a filter function (one for nodes, one for
>> ways and one for relations) in lua that takes in a set of tags and returns
>> a (potentially) transformed set of tags and a boolean flag, if the object
>> should be processed further. For ways, it also determines if it should be
>> treated as a line or polygon.  This should allow for things like
>> normalising the data from "oneway=yes/1/true" or rewriting things like
>> "highway=footway" into "highway=path, foot=de

Re: [OSM-dev] Add an iD link to the Potlatch no-Flash screen

[Peter Wendorff]

Hi.

As far as I see it's entirely possible to add free tags (there's an
expand link/button that shows other tags).
But IMHO it's not enough, because that only shows tags that are not
included elsewhere in the presetted tag stuff.
The problem with this is, that for the presetted stuff it's (or at least
seems to be) impossible to get the raw tags out of it, preventing to
learn them (yes, novice mappers should not have to, but IMHO they should
be able to understand the raw tags).

So this tag list should IMHO show all tags, not only those not exposed
already by even more human readable UI translations.

regards
Peter


Am 22.04.2013 16:50, schrieb Tom MacWright:
> Hi Martin,
> 
>> it seems as if doesn't expose way membership to the user currently. In
> any area with multipolygons or turn restrictions or, likely more difficult
> to fix, other types or relations, mappers will really break a lot without
> even being able to notice.
> 
> It doesn't expose relations in the UI, but does not break them and makes
> the same relatively smart choices as P2 when users make operations on ways
> and nodes in relations.
> 
> "break a lot" is unfounded and untrue: users have been testing iD for weeks
> now and we are not seeing significant problems from this approach.
> 
>> +1 in case of feature X, but freeform tagging is one of the key features
> that really make osm what it is
> 
> What's the assertion here, that iD doesn't support freeform tagging? That's
> entirely incorrect: read the issues and look at the user interface. iD
> supports freeform tagging: just click 'other' and use the tags UI if you
> don't want to use presets.
> 
> Tom
> 
> 
> On Mon, Apr 22, 2013 at 10:45 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
> 
>>
>>
>>
>>
>> On 22/apr/2013, at 16:25, Tom MacWright  wrote:
>>
>>> For super-advanced editing, there will always be JOSM.
>>>
>>> iD does handle relations, though it does not support a relations editing
>> UI at the moment: search for 'relations' in the issue tracker and the
>> commits. There has been a ton of work on the existing relations support,
>> how it interacts with pre-existing relations, and plans for simpler
>> interfaces for editing relations.
>>
>>
>> it seems as if doesn't expose way membership to the user currently. In any
>> area with multipolygons or turn restrictions or, likely more difficult to
>> fix, other types or relations, mappers will really break a lot without even
>> being able to notice.
>>
>>
>>>
>>> Yes: iD has room to grow. But I don't think that the 'a front page
>> editor must include X feature that I think is important' is a useful
>> criteria. If you ask whether an editor has been tested, used, deployed, and
>> generally regarded as safe, iD fits that goal.
>>
>>
>> +1 in case of feature X, but freeform tagging is one of the key features
>> that really make osm what it is
>>
>> Cheers,
>> Martin
> 
> 
> 
> ___
> 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] Coastline changes Antarctica

[Peter Wendorff]

I'm not sure if it works, but I think it might be the better solution to 
have land flooded on the maps than to have water becoming deserts.
On land we might have data which makes errors visually obvious: There 
are streets in the sea - something has to be wrong.
At the ocean we don't have, but in deserts etc. it's the same: There is 
empty land - there might not yet be data here, or there's desert and 
really more or less nothing to see.


Sure: flooded land does not look very well, but I guess it's found and 
fixed faster than water that's rendered as land.


regards
Peter

Am 12.03.2013 10:20, schrieb Tom Hughes:

On 12/03/13 09:17, Jochen Topf wrote:

On Tue, Mar 12, 2013 at 09:12:39AM +, Tom Hughes wrote:


Interesting - that change was Andy's idea and I think the thought
was to reduce the damage done by any breakage and to ensure that
we're not matching any massive polygons in the busy (land) areas.


OSMCoastline first generates the land polygons, them splits them, then
creates the water polygons as inverse from the lang polygons. If the
land polygons are broken, so are the water polygons. So I don't think
you can reduce the chance of breakage that way.


Sure, but the point was to fail to the land background colour not the 
sea so that you don't get "flooding" of the land.


Don't know if it actually works like that but I think that was the idea.

Tom




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

Re: [OSM-dev] Call for A Proper Area Datatype for OSM

[Peter Wendorff]

Am 10.02.2013 21:57, schrieb sly (sylvain letuffe):

Le dimanche 10 février 2013 21:31:28, Jochen Topf a écrit :


Actually the transition is the easy part.

I am uneasy with your use of the work easy ! What will be the harder part !

"Just add support in every editors, most data consumer tools and export/api
side, update the api so you don't download all coastlines at once, run a
script for converting while keeping history intact, still allowing reverts" is
what you would call easy ? I admire your enthusiasm ;-)

Fortunately it should be easy
1) to keep some kind of backward compatibility:
1.a. download from the api: The API could e.g. support a compatibility 
switch that forces returning the new areas as the old ways with an 
additional "area=yes"-Tag. area=yes is in fact already used for stating 
that this feature should be interpreted as an area. Without that switch 
the areas could be produced as the new area-objects/tags.
1.b. upload to the api: For compatibility here the area=yes could be 
some standard tag for "this is an area", which could trigger the api to 
check if it's possible to create an area out of the way or not, and do 
so if it's possible.


2) to enhance editors:
2.a. JOSM: already supports area styling at least; it should not be that 
difficult to introduce the area object as a fourth primitive.
2.b. P2: as far as I know P2 has area support in the sense that areas 
are dealt with differently in code.

2.c. iD definitively handles areas differently already.
2.d: other editors shouldn't be much harder, I would guess - and if it 
takes time, see (1) above.


...provided that (as you mentioned already)...
3) ...the problem of really big areas is solved: Downloading the whole 
coastline of Australia is far too much for many editors, the API and 
often for the main memory is an sometimes impossible challenge. But that 
probably has to be solved nevertheless, and if, I believe, we could find 
a compatible solution again. One idea that comes to my mind might be to 
allow downloading "area-extracts" (as well as way-extracts). This could 
be done similar to what we have for relations already: Relations often 
are not completely downloaded in josm, and the relation editor deals 
well with that issue. For ways something similar could be done:
Load way X in bbox B would lead to all nodes in B (and the next one 
outside) as "real nodes" as well as "pseudo nodes" to provide an 
estimated area around. Editors could use the result for drawing the 
polygon as usual (and for the first time they would succeed in filling 
areas correctly even if not loaded completely, where they fail for 
multi-outer-mp-relations yet), and the API could accept something like 
incomplete-edit-calls for areas, like "edit way X: old node index range 
[3..123] out of version 7 changes to the use of nodes [...] (might 
be less nodes, more nodes or the same node count, but the first two 
nodes keep unchanged, and the nodes behind index 123 doesn't change 
either)". Even more than one node range could be manipulated this way.
I know: there are more issues, even with this short sketch of an idea 
(like e.g. "locking" (you usually can only edit an osm object nobody 
edited since you downloaded it)), but I'm sure it's possible to solve 
these as well.


regards
Peter

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

Re: [OSM-dev] Highway Statistics: counting the number of roads along a junction/roundabout

[Peter Wendorff]

Hi.
I guess most of the roundabouts are not modeled as a relation, and I 
don't think that would be necessary.

A roundabout should be a closed way tagged as highway=roundabout.
=> to get all roundabouts fetch all ways tagged as such.

To count all ingoing/outgoing streets for all roundabouts, I would
- fetch all nodes of that roundabout
- for each of these nodes fetch all ways connected to it
- count them.

Additionally you should
1) look for oneway tags: only ingoing/outgoing
2) for dual carriage ways, especially trunk roads, but often in cities 
that applies to other road types as well, probably you want to find out 
if a pair should be counted as one street only: one ingoing oneway, one 
outgoing oneway, usually they are neighboured, roughly pointing to the 
same direction, and share the same name.
3) depending on your use case ignore footways as they are often 
sidewalks just crossing.


regards
Peter

Am 28.01.2013 12:27, schrieb Martin Alegre:

Dear all,

I need to generate some statistics on highways. More precisely, given 
an OSM file of a city, I would like to find out which is the average 
number of roads along a junction/roundabout?
Does anybody has some experience doing that? Given the OSM 
documentation, it seems to be, that the only way to do that is by 
looking for 's, right? My intuition is that
if inside a given  ... , a junction exists, then 
the rest of 's inside that  are the roads along that 
junction. Is this reasoning correct?

I'm thinking of using Osmium for that purposes.

Best


___
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] area filtering on change streams?

[Peter Wendorff]

Am 21.01.2013 08:00, schrieb Frederik Ramm:

Hi,

On 01/21/13 07:54, Brian Cavagnolo wrote:

I'm kinda hooked on the appeal of only working with the changeset.  I
poked around the osmosis source and learned a bit about the change
format.  It looks like changes could be filtered using the same code
used for the polygon and bounding box filters.  Does this sound
intuitively correct?


No.

The fact that changesets cannot be filtered by region is not a 
software limitation, it is a design limitation.


Changes can occur in nodes, ways, or relations; but only nodes have a 
geometry given in the .osc file. For example, an .osc file might 
contain the information "way #17 has been changed from 
highway=residential to highway=unclassified" but you won't know if 
that is relevant to you because the nodes of that way are not included 
in the changeset (unless by chance they have been modified at the same 
time).
While in fact you would know that (out of the fact, that the way already 
is in your database), the other way around it's a problem:
If a node changes it's location towards your area of interest, that has 
been outside before, every way connected to this node is of interest for 
you, but these ways are neither in your database (outside your area 
before) nor in the change stream (as the way object itself didn't change).


If you really want to pursue this further, read up on "augmented 
diffs" which are reference-complete and would therefore allow such 
filtering: 
http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs


Bye
Frederik




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

Re: [OSM-dev] Fwd: OSM item tracking

[Peter Wendorff]

Hi Christian.

Am 18.11.2012 11:41, schrieb Christian Quest:

I think a better approach is to add a stable ref:* tag to the OSM objects.

I don't understand why that should be a better approach...


That's the approach we have with most opendata available in France. We 
add tags like ref:UAI to schools where this ref comes from an official 
directory of schools. Same with ref:FR:RATP for subway stations and 
bus_stops in Paris area coming from RATP (Paris public transports).
What if I as a mapper replace the imported school, which has been 
imported as a node by a bunch of buildings, a school yard and so on? 
What should I do with a ref:UAI? probably it would be correct to move it 
to the school yard polygon that encloses the other stuff. But what if 
the id refers to the small shop of the janitor selling sweets and stuff 
to the children? Without a better solution it was more or less correct 
to add that to the school node before, but now it's wrong as it's not 
the area that describes this shop.
To successfully handle that I have to know about ref:UAI or I have to 
ignore it and produce errors with respect to your 3rd party tool or 
database using that reference system.


Novice mappers either ignore these and break stuff, or they leave the 
whole school alone to not break anything - but fail to fix existing bugs 
therefore.


It also opens linking possibility to external additional data instead 
of putting sometime too specialized (and changing) data in OSM itself.
If I delete that ref because it's not documented and I'm not able to 
understand it, this fails.
If you (as the group adding these refs) fail to update them anytime in 
the future (no offense, but often a fact), and the school changes to be 
e.g. a primary school getting a secondary for some reason and getting a 
new ref now, it fails, and nevertheless this then broken data will 
persist in the database as nobody will delete it (due to fear being 
criticised for vandalism).
It that aspect, a move toward semantic web would be interesting by 
adding reference to external URI(s) directly on OSM objects.

-1
In that respect and because this has been discussed several times the 
overpass stable ids has been invented to keep the osm objects clean from 
foreign references that nobody is able to check and keep up to date.


regards
Peter

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

Re: [OSM-dev] making osm2pgsql import relations?

[Peter Wendorff]

Am 08.11.2012 01:04, schrieb Martin Koppenhoefer:

2012/11/7 Ákos Maróy :

On 07/11/12 22:12, sly (sylvain letuffe) wrote:

osm2pgsql only uses it's multipolygon building ability when relations
have a tag "type" with value "multipolygon" or "boundary" (unless
patched) relation n°25 for exemple hasn't.

it hasn't on purpose. the relations I use are not used to stitch
together polygons. they are relations in the traditional sense: they
collect various data about the same thing, in this case, an airport. the
related data is a range of lines (runways), points (navigation aids) and
other stuff, like the 'airport reference point', etc.


You could have everything inside the airport polygon with the PostGIS
function ST_Within and without any special relation, but if you are
after special roles in your relation you won't have them with
osm2pgsql. If you use Osmosis for the import you will get everything,
but in the API db schema.
if you use osmosis, even the snapshot schema may be an option. This very 
much depends on your needs.


regards
Peter

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

Re: [OSM-dev] Tagging of multipolygons with holes within holes

[Peter Wendorff]

Idea e.g. for OSMI or something like that:
Is that oddity (inner ways in multipolygons contain the tags of the 
multipolygon) detected and reported as an issue in any QA tool yet?
Probably that would be a good idea for a new issue type/layer, so that 
somewhen in future that could be considered as a data bug without the 
need to keep that as backward compatibiliy stuff.


regards
Peter

Am 17.10.2012 13:13, schrieb Igor Brejc:
On Wed, Oct 17, 2012 at 1:05 PM, Frederik Ramm > wrote:



Igor probably refers to the situation where you have a
multipolygon with an outer and inner ring, and both rings are
tagged landuse=forest. In that particular tagging, which is
supported by most applications as a form of backwards
compatibility, the hole is *not* a forest ;)


Thanks Frederik, that's another one of those "oddities" ;)

Igor


___
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] Tagging of multipolygons with holes within holes

[Peter Wendorff]

Hi Igor.
But if we're talking about topology, why (as I understand it) are you 
trying to force topological stuff in the multipolygon RELATION?

That solves, well... nearly nothing.
You have to do exactly the same work for any topological issues that are 
not described by a mp relation, e.g. because they aren't multipolygons, 
but distinct buildings, forests, water-surfaces or whatever.
There you have to do exactly what you don't want to do here and where 
you want to have further restriction for multipolygon relations.


I would suggest you to work on the progress towards area types to be 
part of the future api: discussion, decision and implementation.
I would like to see additional topology introduced: along, beneath,  
are interesting, but yet difficult to get topological relations for osm 
data users.


But: Keep in mind that editing should not become more difficult for 
mappers. If topology requires to assemble complex relations that's no 
option.


regards
Peter

Am 17.10.2012 12:58, schrieb Igor Brejc:



On Wed, Oct 17, 2012 at 10:35 AM, Peter Wendorff 
mailto:wendo...@uni-paderborn.de>> wrote:


And where's the problem?
The island is part of the area described by the multipolygon, as
every other outer way is, too.
It can be handled exactly the same as long as you don't want to do
special stuff according to topology, but then again topology is
missing for most osm model elements, yet (or: you have to
interpret it from the geometry yourself).


Yes, the key word is topology. Moving beyond the Painter's algorithm 
and simple map rendering. Having the ability to do generalization with 
topology - polygon simplifications, merging of polygons of similar 
landuse, detecting/removing common edges, displacement, amalgamation 
etc. All in order to produce more useful export data or vector maps. 
That's what I've been doing for the last couple of months.


Igor


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

Re: [OSM-dev] Tagging of multipolygons with holes within holes

[Peter Wendorff]

Am 17.10.2012 10:02, schrieb Igor Brejc:



On Wed, Oct 17, 2012 at 9:40 AM, Frederik Ramm > wrote:



The area of the "hole within the hole" does not require special
tagging, as it is covered by the multipolygon itself. If you have
a forest with a hole in a hole, then that hole in a hole is forest
as well.


True, but you need to determine that geometrically (see my previous 
answer) and then apply the tagging rules down the "holes hierarchy".
Most current applications don't need to distinct between a hole in a 
hole (or an "inner outer way") and a second outer way beneath the first 
one, as most current applications don't care about the topology, but on 
the geometry - and there it's only of interest which parts of the canvas 
to fill and which not.


For the topology interpretation again the interpretation of a way as 
"hole in a hole" isn't helpful either, as more often you will have 
different objects inside that you have to consider to be that hole in 
the hole, without a multipolygon being in place.
Therefore it's necessay to implement the logic Frederic described above 
nevertheless.



If you are, on the other hand, thinking of a "lake in the middle
of a meadow in the middle of a forest" situation, then this is not
"hole in a hole" - the forest has one hole which is the meadow,
and the meadow has one hole which is the lake. You would have
three ways:

F - tagged as forest
M - tagged as meadow
L - tagged as lake

and two multipolygons

MP1: outer=F, inner=M
MP2: outer=M, inner=L


Yes, if you split it in two separate multipolygons, then it's clear. 
But the problem is that Wiki does not explicitly forbids (just 
recommends not to) doing it all in a single multipolygon, quote:


Such cascading is still recommended when the "island" in the
middle is something else than the area on the outside, but where
the "island" is the same stuff it can just be made a hole in the hole.


And where's the problem?
The island is part of the area described by the multipolygon, as every 
other outer way is, too.
It can be handled exactly the same as long as you don't want to do 
special stuff according to topology, but then again topology is missing 
for most osm model elements, yet (or: you have to interpret it from the 
geometry yourself).


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

Re: [OSM-dev] osm2pgsql and bbox imports

[Peter Wendorff]

Danke.
Ich hab wohl zu wenig imports bisher durchgeführt und hatte das einfach 
als gegeben hingenommen ;)

Danke fürs untersuchen und dokumentieren.

Gruß
Peter

Am 15.10.2012 00:11, schrieb Stephan Knauss:

On 12.10.2012 18:38, Peter Wendorff wrote:

Am 12.10.2012 18:12, schrieb Stephan Knauss:

Peter Wendorff writes:

osm2pgsql has to store nodes outside the bbox because geometries that
overlap the borders etc. should be included in the result, too.

how certain are you regarding this?

It's only based on my observations and short comments on questions
regarding that in the IRC channels.
My germany extract import took incredibly long and the number of nodes
in the slim nodes table is around in line with the data stats for
Germany as a whole, while I only imported one city (by bounding box
filtering).


I can say it's a bug with pbf processing. I was able to reproduce the 
problem and created a ticket.


https://trac.openstreetmap.org/ticket/4625


I suggest you have a look at the filtering capabilities of osmconvert. 
It was able to extract my desired bbox out of the 2GB asia extract 
within 5 minutes.


The resulting database is now 40 times smaller and in a range I was 
used to before my software upgrade.


Stephan





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

Re: [OSM-dev] osm2pgsql and bbox imports

[Peter Wendorff]

Am 12.10.2012 18:12, schrieb Stephan Knauss:

Peter Wendorff writes:
osm2pgsql has to store nodes outside the bbox because geometries that 
overlap the borders etc. should be included in the result, too.


how certain are you regarding this?
It's only based on my observations and short comments on questions 
regarding that in the IRC channels.
My germany extract import took incredibly long and the number of nodes 
in the slim nodes table is around in line with the data stats for 
Germany as a whole, while I only imported one city (by bounding box 
filtering).
in parse-primitive.c::EndElement() I see a call to node_wanted() which 
only returns true if the coordinates of the node are inside the 
bounding box.

it later calls osmdata->out->node_add
in output-pgsqlo.c this is pgsql_add_node which calls pgsql_nodes_set.
This is calling a prepared statement which inserts the node in the 
planet_osm_nodes table.


My question is: is this code path also used during initial import?
Is this code path used during incremental updates?

My previous imports had used the xml extract as the debian protobuf 
library did not work as expected. I have now also updated protobuf and 
using now pbf as an input file.

The code in parse-pbf::processOsmDataNodes() does not call node_wanted().
Could it be it's simply missing there?
after this line
lon = lon_offset + (node->lon * granularity);
doing the node_wanted call and only then process the node?
In fact I imported a pbf file, so that might be the reason why you 
disagree with my observations.
On the other hand the node_wanted() simple rejecting any node outside 
the bbox would lead to geometries to be cut of or rejected even if 
overlapping the target bounding box.


IMHO this is an acceptable behaviour as an option, but it should not be 
the default.


regards
Peter


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

Re: [OSM-dev] osm2pgsql and bbox imports

[Peter Wendorff]

Hi Stephan.

osm2pgsql has to store nodes outside the bbox because geometries that 
overlap the borders etc. should be included in the result, too.
If osm2pgsql would skip nodes outside while parsing nodes, but before 
parsing the more complex geometries (ways, relations), these nodes would 
be lost later, even if they are necessary, e.g. for a big forest 
spanning the entire area etc.


Yes, preprocessing might be faster therefore, but that might depend on 
your system setup and where the bottleneck of your pipeline is, as the 
cutting process faces the same problem here: it runs several times over 
the input file to find dependent nodes for ways that are partly in the 
extracted target area.


regards
Peter

Am 12.10.2012 09:47, schrieb Stephan Knauss:

Hi,

I'm doing a slim mode bbox import for rendering.

What is supposed to be in the planet_osm_nodes table? All nodes of my 
import source file or only the nodes contained in the bbox?


I used this bbox:
--bbox  "97.3,5.6,109.6,23.4"

and planet_osm_nodes contains for example this:

id;lat;lon
1744503310;1003244360;-1936959139;

Is it supposed to be there?
If so, it would be a lot faster to preprocess the input file with bbox 
clipping before feeding it into osm2pgsql.


Was this changed recently? I have the impression that in the past it 
did not contain these nodes.


Stephan

___
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] baseball cards, user stats and multiple accounts

[Peter Wendorff]

Nice...
Probably baseball cards are different from what I think they are, but 
these collector cards I know are tiny and very compact, so the "flair" 
of them for me comes from that compactness, even if that means small 
font sizes and so on, something I miss in your "pre-design" to make them 
"mapper cards" - but as you say yourself: it's not designed yet ;)


As a small hint on the content: the editor stat pie chart could contain 
the names in the tooltips - or the color key for the editors should be 
included in the table at least - where I prefer the first variant. ;)


regards
Peter


Am 06.09.2012 20:00, schrieb Richard Weait:

I've been interested in the statistical aspects of mapping for a
while, and in baseball cards for even longer than that.

You may have seen this before.  Hang on.  I've added something cool.

One question I come back to frequently is "If mappers had baseball
cards, what would they look like?"  Another is, "If you had mapper
baseball cards, who would you trade for whom? "  That is probably a
topic for another day.  :-)

For today, I've made some updates to my little mapper baseball card
project. I imaginatively call it "UserStat" because I am Just That
Good At Marketing.

So here is a basic mapper baseball card for "rw__".  Hey@  That's me!

http://rweait.dev.openstreetmap.org/daily/rw__.html

Now, that won't win any design prizes, but I'm trying to keep the html
simple and sane so that a Read Designer can come along with some nice
css to make it really rock.

Here's something I didn't know.  I used Potlatch more than JOSM in
only one year.  Hmmm.  I would never have known without the stats and
little graphs.

That's cool, I guess, but I have another account as well, 'rw_'.
Again.  Note the awesome imaginative name.  Here's the card for that
account.

http://rweait.dev.openstreetmap.org/daily/rw_.html

There is something different to learn here.  I didn't use the account
for a couple of years.  And I hadn't used it with Potlatch at all.
That probably speaks to my browser settings in some way.

Here's something new.  What if you could get combined stats for all of
your specialty accounts?  What would all of that combined mapping look
like if it were a single mapper?  Let's find out.  Here are my three
accounts with combined statistics.

http://rweait.dev.openstreetmap.org/daily/rw__career.html

The code is all available in UserStat, the examples are from the
rearrange branch.  Hopefully I'll merge it shortly and move towards a
0.1 release.  You'll want ChangesetMD as well, as that builds the
database the UserStat relies upon.

https://github.com/rweait/UserStat/tree/rearrange

My wishlist:
- mappers to think it's cool and ask for their stats.
- designers to take an interest in making it prettier.
- developers to patch and improve.
- ideas!  What are additional tools that mappers use and how can we
measure them?
- long range: make it all "webby and stuff" and let people serve themselves.

Best regards and happy mapping,
Richard

___
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] Fwd: Fwd: Local Tiles on JSP + Tomcat issue

[Peter Wendorff]

Am 22.08.2012 09:48, schrieb Reshma Maner:

Hi,

I have set up osm2pgsql,mapnik on ubuntu server. I have also generated 
tiles locally.
Now I want to display these tiles on map in a JSP page. I am using 
open layers.
I have been trying it. The code works fine in html, but if same thing 
I do in a jsp page, it does not open map tiles. Only pink canvas is 
displayed. On rightclick, it displayes map tile path as 
"/LocalFolder///.png". source code is given below.
Please let me know what is the procedure I should follow to display 
local map on a jsp page(Tomcat server),

Code:


  var newLayer = new OpenLayers.Layer.OSM("Localhost",
"IndiaMap/${z}/${x}/${y}.png", {numZoomLevels: 4, alpha: true,
isBaseLayer: true});

Here's the correct path required.
I guess, what you call "LocalFolder" above is "IndiaMap", but make sure 
that this relative URL (so base url of the jsp page + /IndiaMap/ leads 
to the corresponding folder.


The HTML page is mapped directly to the file system; the JSP-file is 
mapped differently through the java aware web server.
One possibility is to use the complete URL here, so instead 
"IndiaMap/${z}/${x}/${y}.png" use 
"http://complete-url-like-you-see-it.in/the/image/properties/on/the/working/html-file/IndiaMap/${z}/${x/${y}.png";, 
where - sure, IndiaMap/... should not be doubled.


regards
Peter

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

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

[Peter Wendorff]

Hi Jan.
I didn't use Vespucci, yet, but as a small suggestion, because I thought 
about it while reading your mail:


I assume it's possible to apply several presets to the same object, each 
adding it's tags; at least that's what I'm doing in JOSM e.g. by using 
the fuel template and afterwards adding the address using the address 
template.


Combining this with what you describe about Vespucci, I wonder, if 
Vespucci supports this, too in the autocomplete feature - that more than 
one preset is used for the autocomplete menus.


Second question in the same direction:
If I add addr:street, and that's part of an address preset - wouldn't it 
be nice even if I don't use prefix to get the "common tag combination" 
as suggested by the prefix description in the autocomplete feature?


Just an idea ;)

regards
Peter

Am 01.08.2012 06:40, schrieb Jan Schejbal:

Hi,
Preset support is now enhanced. When applying a preset:

* Fixed tags (i.e. key and value are given) are still added as usual
* Non-fixed, non-optional tags (e.g. text or combo tags) are added with
the key only. If the user saves without entering a value, it will be
removed.
* Non-fixed, optional tags are not automatically added, but considered
when the autocomplete menu is built

The autosuggest now works like this:
* automatically triggered once at least letter is entered (a threshold
of 0 is NOT supported by android, unfortunately)
* Triggered when the user clicks an already-focused input box
* Can be hidden by the back key (default behavior)

* The key autosuggest menu contains
** First, all keys that apply to the preset that was applied (if any)
** Then, all keys in presets fitting the current node type in
alphabetical order (i.e. if a key appears only in presets that can only
be applied to nodes, it will not be suggested when a way is being tagged)
** Keys that are already used are NOT offered again

* The value autosuggest contains all values, in alphabetical order, that
can be applied to the given key

An APK will be provided later.

Kind regards,
Jan

___
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] Useful post-bot visualisation?

[Peter Wendorff]

Am 21.07.2012 00:11, schrieb Michael Kugelmann:

on 20.07.2012 22:51, Frederik Ramm wrote:

Comments are welcome.
looks very (!) promising. Thanks for the work! Looking very forward 
for the "live/production" version.


One hint: maybe the tools should not remove objects touched by someone 
from its display: I checked Helgoland aftzer the redaction bot. And: 
e.g. a few streets had been only left as "way with no tags". So I 
reconnected them at the crossings to other ways according to aerials. 
And I marked them with highway=road as temporary sollution (don't know 
the local situation). And I added a fixme=yes tag (together with a 
note=). => maybe the checker should leave the objects with a fixme 
tag displayed but in another color. 

In future please use fixme= directly.
With your solution others have to investigate more than one tag to see 
what you mean by the fixme.
Even the tools - at least OSMI and keepright - show the content of the 
fixme tag directly, but not the content of the note tag.


regards
Peter

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

Re: [OSM-dev] Reserve node 2147483647

[Peter Wendorff]

Hi.
Why should that prevent errors in software not handling 64bit ids correctly?
I don't think any software requires all possible ids in between to exist 
- even for the whole planet.

So it's not different wether 2147483647 is missing or 42.

regards
Peter

Am 20.07.2012 14:19, schrieb Andrew:

Would it be a good idea if the next node allocated after 2147483646 is node
2147483648? It would mean that applications expecting 32-bit node numbers fail
cleanly and stops buggy editing software from modifying the wrong node.

--
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] Server-side data validation

[Peter Wendorff]

Am 13.07.2012 20:54, schrieb Paweł Paprota:

Hi Peter,

Thanks for the response.


1) The OSM API is a restful api that allows "live" editing: The editor
software a) opens a changeset, b) creates a node, c) adds a tag - same
for ways.
Between b and c there's an untagged osm element in the database (even if
it's in most cases a very short time).

I think that is a rather orthogonal issue to validation, meaning that
some validation should probably be launched when a changeset closes for
example - true - but more important is the fact that even with the API
calls that you described it is not possible to _end up_ with broken
data.

Of course it is.
Imagine the user's internet connection to be broken after (b) and the 
changeset get's closed due to a serverside timeout later.
The database has that empty node and probably even other users already 
use it (by downloading and editing).
It's not possible to invalidate that node completely afterwards, because 
there may be conflicts if you try that.

  So for now I'm trying to discuss this at a more abstract level -
that the contract would be "we can't have X in the database" but how it
is implemented (at changeset close maybe?) - I cannot say (yet) as I am
no expert in OSM. For now more important is whether this kind of
thinking even makes sense for you.
The idea makes sense IMHO, but I don't have an idea how to intelligently 
handle these checks without big changes to the API style.

[...]

3) the free tagging scheme would allow similar stuff for nodes, too
(while I don't know any issue where that's used currently). A
theoretical example would be a set of nodes, which are defined points
inside a fuzzy area/region and others which are defined points outside
(where there's no concrete, hard boundary defined, e.g. for "the alpes".


I understand the benefits of "free tagging" approach. On the other hand
it is kind of strange that even for "core" keys (e.g. "highway" or
"surface") there is no validation/schema/whatever one calls it.
It's the big question what "core keys" are - and what they are allowed 
to contain or not.

What do you want to check for the highway key, for example?
The most prominent values are easy - but there are tons of other values, 
too, that are less easy to "validate", and as long as 
highway=emergency_access_point, highway=give_way and similar are 
"allowed", how to reject invalid highway-tags?

In this case, what is more efficient:

1. Adding one more possible value for "highway" when it is needed and
deploying such a change to production.
2. Constantly cleaning up the database when there are inconsistent
entries (typos etc). In fact I think there is no such process as global
cleanup - there are couple of bots that do so here and there but overall
the data can be inconsistent.

Sure.
But if you decide for the first variant, Mary Mapper cannot decide to 
add a useful highway=electrocycleway for the increasing amount of 
e-bikes, because the server would reject that tag.
The rails coders have to decide to change that, before anyone can add 
that tag.
Sure: We can assume that seldom a new value for highway will appear - 
but is that helpful?


I think, again Multipolygons are some kind of a special case, but from 
another point of view: Multipolygon basically is in fact the current 
fourth basic datatype of OSM.

Pushing this validation to the server side has several drawbacks:
- usually server load is the bottleneck in osm, not client load.

I understand infrastructure constraints but I think (very-)long-term
pushing stuff to the client-side will cause much more trouble than
dealing with load issues but having consistent database and business
logic (validation) in place.
True, as long as you really can restrict the tagging. As mentioned: that 
brings other problems as it kills the free tagging even in corner cases, 
where that's the big benefit of osm.

- a check on server side would fix the corresponding tagging and makes
other tagging schemes invalid probably, a contradiction to the free
tagging scheme we have.
- the api would have to change to use transaction like semantics, wich
is again higher server load, but the only way to make sure not to create
these invalid stuff.

For now it is just a thought exercise and discussion but if I could
propose some changes and perhaps implement some proof of concept, would
it be taken seriously? You can say that "open source is about working
not talking" and I should rather do something instead of discussing but
as you can see these are pretty high level things that go against status
quo - that's why I want to make sure my time is well spent...

well...
I fear, I'm not someone really big in coding (for osm) yet, I looked 
into the rails code, but don't know rails ;)

So probably I'm the wrong one to ask.

But usually as far as I can see solutions are taken seriously usually - 
if they follow the right path; and that right pass might not be what 
someone imagines - especially if it's not discussed before

Re: [OSM-dev] Server-side data validation

[Peter Wendorff]

Am 13.07.2012 20:08, schrieb Jochen Topf:

On Fri, Jul 13, 2012 at 08:04:10PM +0200, Peter Wendorff wrote:

1) The OSM API is a restful api that allows "live" editing: The
editor software a) opens a changeset, b) creates a node, c) adds a
tag - same for ways.
Between b and c there's an untagged osm element in the database
(even if it's in most cases a very short time).

No, thats not the case. Objects always have their set of tags with
them.

Sure?
As far as I read the API documentation, it's in fact possible to do it 
exactly that way, doing the following separate API calls:


1) open a changeset
2) create an untagged node (possible, as untagged nodes in general 
aren't invalid as such)

3) add a tag to that node
4) close the changeset.

sure, the editor of your choice MAY and usually will add tags directly 
before the first upload, since the usual way to edit nowadays isn't the 
live mode; but it's afaik not restricted by the api.


regards
Peter

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

Re: [OSM-dev] Server-side data validation

[Peter Wendorff]

Hi Pawel.
Some reasons - perhaps more exist:
1) The OSM API is a restful api that allows "live" editing: The editor 
software a) opens a changeset, b) creates a node, c) adds a tag - same 
for ways.
Between b and c there's an untagged osm element in the database (even if 
it's in most cases a very short time).
2) Ways without tags may be part of relations nevertheless: an outer way 
of a multipolygon does not necessarily have tags, as the tags applied to 
the multipolygon should go to the relation.
3) the free tagging scheme would allow similar stuff for nodes, too 
(while I don't know any issue where that's used currently). A 
theoretical example would be a set of nodes, which are defined points 
inside a fuzzy area/region and others which are defined points outside 
(where there's no concrete, hard boundary defined, e.g. for "the alpes".


Pushing this validation to the server side has several drawbacks:
- usually server load is the bottleneck in osm, not client load.
- a check on server side would fix the corresponding tagging and makes 
other tagging schemes invalid probably, a contradiction to the free 
tagging scheme we have.
- the api would have to change to use transaction like semantics, wich 
is again higher server load, but the only way to make sure not to create 
these invalid stuff.


regards
Peter

Am 13.07.2012 19:27, schrieb Paweł Paprota:

Hi all,

Today I have encountered a lot of bad data in my area - duplicated
nodes/ways. These probably stem from an inexperienced user or faulty
editor software when drawing building. I corrected a lot of this stuff,
see changesets:

http://www.openstreetmap.org/browse/changeset/12208202
http://www.openstreetmap.org/browse/changeset/12208389
http://www.openstreetmap.org/browse/changeset/12208467
http://www.openstreetmap.org/browse/changeset/12208498

As you can see, these changesets remove thousands of nodes/ways. I have
done this using JOSM validators and "Fix it" option which automatically
merges/deletes nodes that are duplicated.

That is all fine of course but this sparked a thought... why is this
garbage data like this allowed into the database in the first place? Of
course it can always be fixed client-side (JOSM, even some autobots) but
why allow an unconnected untagged nodes or duplicated nodes, duplicated
ways etc.?

I understand (though don't wholly agree...) the concept of having a very
generic data model where anyone can push anything into the database but
it would be trivial to implement some server-side validations for these
cases (so that API throws errors and does not accept such data) and thus
reduce client-side work by a very significant margin - i.e. I could have
been working on something more useful in that time than removing garbage
data.

Server-side validation could be of course taken even further - OSM
server could reject meaningless tag combinations etc. - basically JOSM
validators on the "error" level should be implemented as server-side
validators, some "warning" level validators possibly as well.

This would ensure data consistency and integrity at least a little
bit... (of course first bad data would have to be pruned from existing
database so that it is consistent with validation logic but that's for
another discussion).

What is the current consensus within OSM dev community on this aspect of
OSM architecture?

Paweł

___
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] (Multi)Polygon handling

[Peter Wendorff]

Am 13.07.2012 18:31, schrieb nimix:

Hi, I just has a look at this... Mapnik indeed has no such requirement. But
it requires inner rings of multipolygons do be in a different orientation
than the outer ring. Hence it is reasonable to ensure that by just making
all outers cw and inners ccw.

That won't work everywhere:
If a polygon is outer way of multipolygon 1 and inner way of 
multipolygon 2, it would require to be cw and ccw.
Therefore as long as the way is a way (independent of ~ or part of 
multiple ~ respectively) multipolygons, it's direction can be arbitrary 
and cannot be fixed to be one particular for multipolygon restrictions.


regards
Peter

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

Re: [OSM-dev] (Multi)Polygon handling

[Peter Wendorff]

Am 13.07.2012 10:13, schrieb Paul Norman:

From: nimix [mailto:melchiorm...@gmail.com]
Sent: Friday, July 13, 2012 12:58 AM
To: dev@openstreetmap.org
Subject: [OSM-dev] (Multi)Polygon handling


Frederik Ramm wrote


If we can't get everyone to use the same code base, then it would at
least be great to reach some kind of agreement here, or maybe at least
produce a test suite that everyone runs their code against.



I created a testsuite for that with some more cases that need special
treatment. Unfortunately I only stored the WKB representation in Google
mercator projection, so it is not very human readable. The testcase
contains a LINESTRING and a MULTIPOLYGON for simple closed ways and for
relations a MULTILINESTRING and a MULTIPOLYGON ([1]).

I would volunteer to bring it in an other format so that it is useful
for everyone writing converters and I would like to discuss what is the
best way to do it. I would suggest an .osm file and a Wiki Page
containing the expected results in WKT/WKB and some explanation for each
case. Any other ideas?
Best regards,
Melchior

My following of web standards has convinced me it is necessary to define the
expected output in every case, including invalid ones, or you will have
differing implementations. I've been giving it some thought as to what needs
to be tested, and I don't think it's excessive. I'd estimate 25-50 small
tests would cover everything.

+1
But it should be possible to reject false polygon models.
So to say:
- any application "must" deal with correct tagging in the same way 
(which is defined by the corresponding test cases)
- if an application interprets wrong polygons, it "must" do it in the 
way which is defined by the corresponding test cases
- but(!) every application is allowed to reject these polygons because 
of errors
- any application is encouraged to report wrong polygons detected to 
users who may be able to fix that in the database.


("must" of course only to correctly claim "standard" osm polygon handling)

regards
Peter


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

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

[Peter Wendorff]

Am 11.07.2012 04:58, schrieb Paul Norman:


What exact attribution does OSMF intend to use when the tiles are a 
mix of old tiles and new tiles?



As far as I know the Tile license should not change, right?
The attribution therefore could mention both probably or determine it 
tilewise by date (tiles rendered after final license switchover/rendered 
before). The render timestamp is known for all tiles.


But no idea what's planned by the admins (btw.: osm.org does not use any 
attribution anyway for the data source, so whay should change? at that's 
fact for the last months/years, any (new) discussion about if that's 
necessary could be shifted a few more weeks/months.


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

Re: [OSM-dev] "Retina" tiles - best way to support them?

[Peter Wendorff]

Am 05.07.2012 09:44, schrieb Frederik Ramm:

Hi,

On 06/27/2012 01:10 AM, Robert Joop wrote:

3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, 
just

on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.



This option sounded best to me as well.



I just tried this out and found that, on a standard non-mobile
Firefox browser, OpenLayers displays the new 512x512 tile just fine,
it scales it to 256x256 in the browser. I can then use the browser's
"zoom" function to blow up the OpenLayers display and while
everything becomes jaggy when I do this with normal tiles, the map
still looks nice when using the double resolution tiles. Does this
mean that it would be an acceptable viewing experience for mobile
users as well?


Most likely, I’d guess.
I’d like to try it on some devices with pixel ratio > 1, like the Nexus
One with its penTile display
http://en.wikipedia.org/wiki/Nexus_One#Hardware
or the iPhone 4.
Is your test setup publicly accessible?


It is now, here:

http://mull.geofabrik.de/hires.html

By default this will come up with standard Mapnik tiles from osm.org, 
but you can switch to my hires tiles in the layer switcher. If I do 
this in Firefox on my desktop machine, there's hardly any difference 
between the two, as OL downscales the images from 512x512 to 256x256 
for display. Only if you right-click on an image will you see that it 
is indeed bigger than normal.

You may simply zoom in in Firefox using Strg+"+" to see the benefit ;)

regards
Peter

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

Re: [OSM-dev] Anomaly detection. Ref Adam, Deric

[Peter Wendorff]

Hi.

Am 15.06.2012 12:04, schrieb Sandor Seres:


-Detect erroneous roundabouts (RA) in a road/class, for instance in 
primary roads. There are many, many of them. There are ordinary road 
sections tagged as RA, RAs tagged as ordinary road sections (or not 
tagged as RAs),


How should the last issue be detected? At least in Germany a circular 
street and a roundabout have different rules for the traffic, but both 
is possible. Therefore not every small circular road is a roundabout - 
but +1 for the other cases (as a possibility, not necessarily as a 
primary topic for this project).


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

Re: [OSM-dev] Same node shows up multiple times in changeset

[Peter Wendorff]

Am 13.06.2012 18:45, schrieb Peter Körner:

Am 13.06.2012 18:35, schrieb Eric Wolf:

I am using a dated fork of the Rails Port, so I am hoping this has been
fixed already. I am seeing occasional changesets with the same node
showing up multiple times.
The Api does nor prevent this. If an Editor chooses to upload a new 
Version of a Node without Changing anything, then it is like that.
and as a changeset isn't a transaction, even multiple consequent edits 
of the same object may happen in the same changeset: you can add a tag 
first, upload that change (as part of changeset x) and change the node 
again later to upload it again as part of the same changeset x.


regards
Peter

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

Re: [OSM-dev] determining the boundaries of cities?

[Peter Wendorff]

Hi Ákos.
I fear, we don't have that distinction, as it's not that clearly 
separatable:


Am 31.05.2012 09:15, schrieb Ákos Maróy:
 for example when you drive on the road, you encounter a city limit 
sign at the end of the city, and then afterwards you can drive with 
different speed limits. 
In Germany the speed limit is the case by default, but in the city there 
may be different limit signs even increasing that.
One problem with this kind of "boundary" is, that it's only defined 
along streets, not on every small way and not in between.
One proposal to tag this is [1], referring not to the boundary, but to 
the points on the boundary where the city limit starts.


On the other hand there's [2], the maxspeed-key and the addition as 
source:maxspeed, which can be source:maxspeed=DE:urban and so on.


also, within city limits, there are certain services the city 
provides, like a residential road, water, electricity, gas, public 
lighting, etc. outside of the city this is not provided. this is the 
city limit I'm looking for 

In Germany this distinction is not true.
As far as I know this kind of public infrastructure is provided in areas 
that are planned to be used for a specific purpose like building houses 
or sth. like that.
There may be areas in the rural area where no power is provided, but 
other places may have power, e.g. because there's a farm or a fuel station.
On the other hand there may be parts in cities, that have not (yet) 
water supply because there's nothing built or going to be built yet.

Therefore perhaps the area with continuous cover of buildings is the
target, which corresponds to the reality in the sense of "realizing" it
if you go out.

my hope was that landuse="residential" would show this aspect, but it
doesn't :(
landuse=residential should match areas mainly used for residenting - 
houses to live in.

parts of cities clearly are at least:
landuse=commercial
landuse=cemetery
landuse=brownfield
landuse=construction
landuse=garages
landuse=greenfield
landuse=industrial
landuse=railway
landuse=retail
landuse=village_green

but not the other way around, e.g.:
there may be landuse=construction that does not belong to cities.
there may be landuse=railway outside of cities

what is the intended way of showing what is an urban area, and what is
rural?
I don't think we have something like that, as - see above - the big 
question here remains: what is an urban area and what is a rural one?


regards
Peter

[1] http://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit
[2] http://wiki.openstreetmap.org/wiki/Maxspeed

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

Re: [OSM-dev] determining the boundaries of cities?

[Peter Wendorff]

Am 31.05.2012 02:58, schrieb Paul Norman:

From: Ákos Maróy [mailto:a...@maroy.hu]
Subject: [OSM-dev] determining the boundaries of cities?

Hi,

I wonder what is the best way to determine city boundaries based on the
OSM dataset. What I want to do is simply to have each city colored in
light yellow (uniformly), with a black outline at the edge of each city.w
I'm not concerned about the streets inside the cities, etc.

I looked at the OSM data for Hungary, and of course at the OSM Wiki, but
I'm still yet to be able to determine the best way to achieve the above.

One possibility seemed to be to go with:

boundary = administrative&&  admin_level = 8


but this will actually create a full tiling of the map - the edges of
these areas not the edges of the cities themselves, but they 'fill up
the space' up to the neighboring such areas. basically the 'rural area'
between the cities is filled up

In many places this is correct. Frequently there is no land between cities -
all the land is in a city. For example, in Greater Vancouver all the land
belongs to one city or another, including the farmland.

I think, that's legally correct, but probably not, what is needed here.
Even if legally every location is legally assigned to a city and legally 
part of it, it's not what a map should show in every case.
A map that should show cities may be targeted on the city as a social, 
cultural entity, not as a legal one.
Therefore perhaps the area with continuous cover of buildings is the 
target, which corresponds to the reality in the sense of "realizing" it 
if you go out.


regards
Peter



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

Re: [OSM-dev] GSoC - Data Tile Service

[Peter Wendorff]

Am 25.05.2012 02:23, schrieb Michael Daines:

* Problem: Since we are speaking about "vector tiling" it's
unavoidable that polygons are clipped, which makes me wonder on how
the client is informed and how he should deal with this?

I'm not sure if I have a complete answer for that yet. Do you have any 
suggestions?

One possibility is to do what the API does for bbox queries, where complete 
geometry for ways with a node intersecting the tile is included, and also the 
relations which refer to the stuff in the tile, but that's it. (So if you have 
a tile intersecting with the border of a country, you don't get the entire 
border, just one part of it.)
AFAIK osm polygons don't have a fixed drawing direction, they may be 
drawn clockwise or counter-clockwise.
Including a part of the polygon only would therefore not be enough, as 
the consumer cannot decide how to draw that part anyhow filled without 
being able to decide about which side of the line is inside and which is 
outside.


regards
Peter

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

Re: [OSM-dev] Updating own tile server

[Peter Wendorff]

osmosis 0.31 is far outdated.
current version is 0.40
compare http://wiki.openstreetmap.org/wiki/Osmosis

This may solve your problems, but even if not you should update your 
osmosis software.


regards
Peter

Am 12.04.2012 08:36, schrieb Anwar Azulfa:

I fount http://www.hyperionreactor.net/blog/how ... r-database
But when i execute
/./osmosis --read-replication-interval-init 
workingDirectory=/mnt/changesets//


i got error messages like bellow :

/pr 12, 2012 1:18:05 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.31
Apr 12, 2012 1:18:06 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Apr 12, 2012 1:18:06 PM org.openstreetmap.osmosis.core.Osmosis main
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task type 
read-replication-interval-init doesn't exist.
at 
org.openstreetmap.osmosis.core.pipeline.common.TaskManagerFactoryRegister.getInstance(TaskManagerFactoryRegister.java:60)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.buildTasks(Pipeline.java:50)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.prepare(Pipeline.java:112)

at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:79)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)/


What;s wrong with it ?
help me, please

On Thu, Apr 12, 2012 at 10:26 AM, Anwar Azulfa > wrote:


Hi All,

I want to update my Map on My Tile Server because i think every
time map on OSM server being updated.
Anyone could help me ? How to get it ?

Is with update database only it's can solve ?

Is there update script for it  ?

Thanks

-- 
Regards,

M.Iftakhul Anwar





--
Regards,
M.Iftakhul Anwar




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


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

[OSM-dev] Overpass-API error codes

[Peter Wendorff]

Hi.
In a software I'm going to use the Overpass-API to fetch OSM-Data, and I 
think about handling error codes.
As far as I see, Overpass prints errors in a -Tag in human 
readable text, but nowwhere as machine-readable text, while most error 
codes I guess could be mapped on HTTP-response states.


Is it planned (or a good idea that's planned now ;) ) to add a machine 
readable error state somehow?
this could be done e.g. by adding a error-code attribute to the 
remark-attribute.


regards
Peter

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

Re: [OSM-dev] [OSM-talk] Map key on osm.org

[Peter Wendorff]

Hi.
Preface: I'll copy this mail to the dev@openstreetmap.org list, too, so 
please restrict to one list when answering; but I think, this mail deals 
with dev-issues, too and parts of the discussion might progress better 
on dev.


I don't see the English descriptions, so I hope to guess the right keys 
for you.
Most issues I list here are missing or obsolete items. Errors (where the 
map key and the map differ) are marked as ERROR! if you only want to 
deal with these.

German descriptions in paratheses.
I checked everything up to zoom level 10, afterwards it's difficult as 
both, map and key get more crowded. So in higher zoom levels I restrict 
to errors and issues I see by accident.


Btw: What about generating the map key from the stylesheet 
automatically? Is there any ongoing work on that?



level 0: renders only land and water, but map key contains motorway 
(Autobahn), trunk (Schnellstraße) and Country? These are not shown up to 
level 4. borders (Landesgrenzen, sonstige Grenzen)
level 1: similar to 0, borders are shown, the other two are "obsolete" 
in the map key

level 2, 3: missing key for Country labels
level 4: no differentiation between the two, but different border types 
(countries vs. states)

level 5: missing key for Capitals
level 6: glaciers are missing (but quite prominent e.g. in the Alps). 
Meaning of the city label changes (compared to lvl5): includes 
additional big cities.

level 7: national parks are missing, but rendered (light green)
level 8: map shows forests/woods (very prominent), but that's not in the 
map key
level 9: missing key for agricultural landuse (Landwirtschaft in level 
10), but prominent in many areas. Rivers missing
level 10: Motorway key should contain the shield (as common in 
"commercial" maps), Airports are missing, restricted areas are missing 
(the red, diagonal striped areas)
level 11: trunks and primary roads are rendered with shields in the map, 
should be reflected in the map key; motorway links are rendered as small 
numbers, but not in the map key. Peaks are missing in the map key; 
nature reserve(?) (rendered as small green NR "icons" on areas) is 
missing in the map key

level 13: tertiary is missing in the map key



well... on a deeper look the "error" I saw is no error (secondary and 
tertiary are similar, and I interpreted the secondary map key for a 
street that was a tertiary in the map, while in that area no secondary 
is present).


Nevertheless: Anything that counts against generating the map key in 
general out of the stylesheet?
If that would be possible, we could additionally support the 
opencyclemap, public transport map (afaik both rendered with mapnik, 
too) and probably even Mapquest, if they support this.


Is there any development on 
http://svn.openstreetmap.org/applications/rendering/mapnik/legend.py ?
Probably that is a good starting point for automatic generation of the 
map key?


regards
Peter


Am 22.03.2012 14:42, schrieb Steve Chilton:

I produced the images (ages ago).
If there are anomalies in the colours or symbols please let me know as I can 
change them.
They are deliberately a subset of all the possible entities that could be 
included.

Cheers
Steve

Steve Chilton, Learning Support Fellow
Educational Development Manager
Centre for Learning and Teaching Enhancement
Middlesex University
phone: 020 8411 5355
email: ste...@mdx.ac.uk
Profile: http://www.middlesex.wikispaces.net/user/view/steve8

Chair of the Society of Cartographers: http://www.soc.org.uk/
Chair of ICA Neocartography Commission: http://www.soc.org.uk/neocartography/


-Original Message-
From: Tom Hughes [mailto:t...@compton.nu]
Sent: 22 March 2012 13:37
To: Peter Wendorff
Cc: t...@openstreetmap.org
Subject: Re: [OSM-talk] Map key on osm.org

On 22/03/12 13:23, Peter Wendorff wrote:


How is the map key (german: Legende) generated on osm.org?
It looks like it is out of sync for the mapnik rendering (viewing from
Germany, description texts are in german).
- some items are not matching between map key and map
- many items rendered in the map are not reflected in the map key

Has this e.g. to be generated for an updated mapnik stylesheet?

It's completely manual - at some point somebody gave me a load of images
and text and I build a key from them.

Tom




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

Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations

[Peter Wendorff]

Am 02.03.2012 13:44, schrieb Peter Körner:

Am 01.03.2012 15:26, schrieb sly (sylvain letuffe):
By "meannings" I mean that some relations are made to build a bigger 
geometry
(type=multipolygon is one), some to records facts unreleated to 
geometry (i.e

type=restriction )

The question is how do we improve that, while keeping free tagging 
system ?


By defining algorithms to work with relations in one place and mapping 
relation-types to that algorithms in another place.


For example:
type=multipolygon --> build-polygon
type=route--> build-linestring
type=waterway --> build-polygon
type=restriction  --> discard
... or type=restriction --> generate-node (to display a propriate icon, 
a node right to (or left in GB) the "from" way with attributes 
restriction=no-left-turn, orientation=25° could be used by the renderer 
later to display a turn restriction icon on the map. As I would propose 
to define the use of algorithms to be configured in any way, that would 
be optional anyways.

type=windmils --> collect

The goal should be reducing the number of algorithms and re-using them 
as much as possible.
I agree, as long as "as much as possible" refers to the re-use only. 
Additional (and useful!) algorithms don't harm if they are not used.


regards
Peter

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