Stephan Bösch-Plepelits | 21 Sep 10:50 2014
Picon

[OSM-dev] Multipolygon support for Osmosis pgsnapshot

In my opinion, one of the biggest disadvantages of the pgsnapshot schema of
Osmosis (compared to e.g. osm2gpsql) is the missing multipolygon support.

Years ago I created scripts for the OpenStreetBrowser, based on a pgsimple
import (pgsnapshot was not yet available at that time), for multipolygon
support and derivative tables. Those scripts were never released separately
and therefore nobody knows about them (I guess).

Now, I just adapted them to the pgsnapshot schema and Postgis 2.0 and
concentrated on the multipolygon support (no derivative tables any more)
and released them as separate repository:
https://github.com/plepe/osmosis-multipolygon

After an initial osmosis pgsnapshot import, you load those scripts and they
will create a simple 'multipolygons' table with the columns: ( relation_id,
tags, geometry ). If you use replication to keep your database up-to-date,
the 'multipolygons' table will also update (the scripts overwrite the
osmosisUpdate() function).

Have fun!

greetings,
	Stephan
--

-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,---------------------------------------------------------------------.
| Stephan Bösch-Plepelits,                                            |
| Technische Universität Wien   -    Studien Informatik & Raumplanung |
| Projects:                                                           |
| > openstreetbrowser.org > couchsurfing.org > tubasis.at > bl.mud.at |
(Continue reading)

Simon Poole | 18 Sep 16:57 2014
Picon

[OSM-dev] Transifex OpenStreetMap Organisation


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

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

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

Simon

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Robert Whittaker (OSM lists | 17 Sep 14:09 2014
Picon

[OSM-dev] Cache settings for OSM Mailing List monthly index pages

I'm not sure if this is the right list to post this to, but I've
noticed recently that I have to refresh the index pages of OSM mailing
list posts e.g.
https://lists.openstreetmap.org/pipermail/talk/2014-September/date.html
in order to get new posts to show up. This seems to happen to me with
multiple browsers on different computers.

Looking at the HTTP headers sent with that page, I see the following:

Cache-Control: max-age=15552000
Expires: Mon, 16 Mar 2015 11:49:55 GMT

I think this is instructing my browser, and any web caches along the
way, that the version of the page I fetched before can still be
considered up to date for the next six months. Such a setting may be
appropriate for the index listing for previous months, as these pages
generally shouldn't change. (The setting would be beneficial there to
help reduce unnecessary traffic.) But surely these settings shouldn't
be used on the current month's page, where new posts are expected
daily.

I tend to check the OSM mailing lists by viewing those index pages, so
it's annoying to have to manually press refresh every time. I'm
guessing that this may well be a mailman issue rather than an OSM one,
but I thought it best to ask here first.

Robert.

--

-- 
Robert Whittaker
(Continue reading)

Sandor Seres | 15 Sep 19:02 2014
Picon

[OSM-dev] Moving to stricter multipolygon parsing, again

Hi Paul Norman

Not so long time ago you have triggered a discussion with your article “Moving to stricter multipolygon parsing”. The discussion lasted two/three days, was intense and rather divergent (demonstrating that the multi-polygon issue is still not “only for beginners”). After that I have not seen or heard anything related to the issue on this forum. So, my question is what happened?

As I understand, your suggestion is to allow tags only on the MPR level and these tags should be none-conflicting (well, the WIKI documentation shows that this was the original intention with MPR). The suggestion could have large positive impact on the (area class) data quality. Therefore I fully support the suggestion but yet I am not sure about the implementation.

To shorten the discussion I would mention just a few arguments causing the dilemma to me.

1. Your implementation is based on the assumption that the mappers will check (lookup) the edits in a map that uses osm2pgsql as a parser. What if the MPR conversion to geometries is not using osm2pgsql? Here the mappers will still probably see the edits no matter where they put the tags. So, the restrictions should come much earlier, probably in the editor systems.

2. At the same time, inserting the suggested restrictions in editors will cause contradictions with the fundamental OSM documents. The WIKI sections defining and illustrating the Relation and MPR notions not only allow but even suggest putting tags on the members (even on border segments, on holes…). So, in my opinion, the restrictions should be first implemented in the OSM wiki documentation by refining/correcting the related sections.

3. Finally, the assumed “do-ocracy” (someone, once in the future, will detect and correct the error) does not work very well. There are many reasons to that. Let me mention two. There is a huge number of errors (significant and “systematic” not counting POI related and of semantic nature). So, it is maybe illusory to assume that the do-ocracy can cope with so many of them. Further, many of these errors are never visible in raster maps, mostly used by mappers. Consequently, do-ocracy will probably even not detect them. But the errors are there and in layered vector mapping these will be probably immediately visible. Just take the large number of river sections tagged as lakes (or the contrary), replicated or almost replicated areas/MPRs with different structures or just take the thousands of closed riverlines (waterway=river).

Now, if these dilemmas are not only mine, then I would suggest an alternative implementation model:

1. An OSM voluntary expert team should go through the WIKI documentation and refine the MPR related notions and implement the restrictions.

2. The editor systems, used by mappers, should accordingly implement the mentioned restrictions.

3 The expert team should use programs to detect the MPR related “systematic” (versus random) errors and programmatically correct them in the source data.

Thanks for the attention, Sandor.

 

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Frederik Ramm | 15 Sep 12:08 2014

[OSM-dev] Karlsruhe Hack Weekend 18-19 Oct

Hi,

    we'll have another hack weekend in Karlsruhe on 18-19 October.
Details, as always, on the Wiki:

https://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2014

Bye
Frederik

--

-- 
Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00'09" E008°23'33"

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Simon Poole | 11 Sep 23:22 2014
Picon

[OSM-dev] Wikimedia Foundation Job Offering


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

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

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Paul Norman | 6 Sep 20:57 2014
Picon

[OSM-dev] openstreetmap-carto upgrade, new features, interesting issues

After a delay for hardware reasons (a drive having issues in a rendering
server), the "Standard" stylesheet on OpenStreetMap.org has been
upgraded to v2.20.0 of openstreetmap-carto. As always, a full list of
changes can be found at github, via
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.18.0...v2.20.0

Significant changes include

* Splitting ref tags to render refs as multi-line shields. This
   rendering is probably the best we can do until Mapnik 3 becomes
   common (#750)
* Rendering crossroad names, a feature common in parts of Asia (#813)
* Steps to fix the cyan from small water bodies at low zoom. This should
   also stop over-representing water at low zooms. (#878)
* Migrating the last of the issues from the old style over from trac
* Adjusting zoom levels where features are displayed to be more consistent
* Improved ordering of POIs (#860)
* Bugfixes

A couple more interesting issues open include

* Ways to move away from the .mml format. We are hitting limitations with
   the JSON layers file causiung difficult merge conflicts, as well as
   generally being a pain to edit, and are looking at alternatives:
https://github.com/gravitystorm/openstreetmap-carto/issues/711

* Dealing with broken boundaries where the ways lack admin_level and
   boundary tags. Worldwide coverage is reasonable, but some countries
   are missing a lot of data, principally Poland, Azerbaijan, Uganda,
   and some untouched TIGER data:
https://github.com/gravitystorm/openstreetmap-carto/issues/344#issuecomment-49535342 

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Mikel Maron | 3 Sep 17:46 2014
Picon

[OSM-dev] Build OpenStreetMap Tools for Conservation

Moabi is looking for a developer to lead the team customizing the OSM stack for forest conservation in DRC and elsewhere.
Check out the details and apply!

Thanks
Mikel
_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
sukhjit sehra | 28 Aug 15:21 2014
Picon

Re: [OSM-dev] dev Digest, Vol 113, Issue 7

Hello, 

Can you please share the data mining techniques can be employed on OSM data.

regards


On Mon, Aug 18, 2014 at 5:30 PM, <dev-request <at> openstreetmap.org> wrote:
Send dev mailing list submissions to
        dev <at> openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.openstreetmap.org/listinfo/dev
or, via email, send a message with subject or body 'help' to
        dev-request <at> openstreetmap.org

You can reach the person managing the list at
        dev-owner <at> openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."


Today's Topics:

   1. How to handle these issues? (Sandor Seres)
   2. Re: How to handle these issues? (Mateusz Konieczny)


----------------------------------------------------------------------

Message: 1
Date: Sun, 17 Aug 2014 15:04:19 +0200
From: "Sandor Seres" <sandors39 <at> gmail.com>
To: <dev <at> openstreetmap.org>
Subject: [OSM-dev] How to handle these issues?
Message-ID: <00cd01cfba1b$c3091770$491b4650$ <at> gmail.com>
Content-Type: text/plain; charset="us-ascii"

I am not quite shore how to handle the following two dilemmas:

1.If a rendering system renders the planet-sea area objects (instead of
planet-land area objects), is then Antarctica a hole in the global ocean
object or the global ocean object simply ends by the upper border-line of
Antarctica?

2.There are around 25460 objects in the class defined by the tag
natural=land in the latest dump. The wiki documentation for the same tag
says "This tag should not be used". How to interpret this?

Are editors refusing data with this tag? Should we ignore the data with this
tag in the dumps? Looking at different OSM based maps I see that I am not
the only one confused with the issue. Unfortunately, the class contains area
objects related to all water types/classes so, this is not just

rendering them at certain stage. In vector mapping, as you certainly know,
it is much more complicated.

Thanks for suggestions/meanings.

Sandor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20140817/d385fb56/attachment-0001.html>

------------------------------

Message: 2
Date: Sun, 17 Aug 2014 18:51:43 +0200
From: Mateusz Konieczny <matkoniecz <at> gmail.com>
Cc: dev <at> openstreetmap.org
Subject: Re: [OSM-dev] How to handle these issues?
Message-ID:
        <CALDvra60Pa6-L8YPaFSXx8B03mrePz905dgtQ+W80_YLgdb1QA <at> mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

ad 2)
- natural=land tag was used
- multipolygons were used to achieve the same goal
- multipolygons are better (solution of general problem), so natural=land
was described as bad idea
- existing natural=land gets replaced by multipolygons what is ongoing
process (see
http://taginfo.openstreetmap.org/tags/natural=land#map for progress - for
example in central Europe this tag is gone or was never used)
- JOSM since https://josm.openstreetmap.de/changeset/7391/josm encourages
users to update tagging (4 days ago)

Tag may be either used to use full available data or be ignored to make
data processing easier and encourage update of tagging.


2014-08-17 15:04 GMT+02:00 Sandor Seres <sandors39 <at> gmail.com>:

> I am not quite shore how to handle the following two dilemmas:
>
> 1.If a rendering system renders the planet-sea area objects (instead of
> planet-land area objects), is then Antarctica a hole in the global ocean
> object or the global ocean object simply ends by the upper border-line of
> Antarctica?
>
> 2.There are around 25460 objects in the class defined by the tag
> natural=land in the latest dump. The wiki documentation for the same tag
> says ?This tag should not be used?. How to interpret this?
>
> Are editors refusing data with this tag? Should we ignore the data with
> this tag in the dumps? Looking at different OSM based maps I see that I am
> not the only one confused with the issue. Unfortunately, the class contains
> area objects related to all water types/classes so, this is not just
>
> rendering them at certain stage. In vector mapping, as you certainly know,
> it is much more complicated.
>
> Thanks for suggestions/meanings.
>
> Sandor
>
> _______________________________________________
> dev mailing list
> dev <at> openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20140817/79ea171d/attachment-0001.html>

------------------------------

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


End of dev Digest, Vol 113, Issue 7
***********************************



--
Er. Sukhjit Singh Sehra
Assistant Professor
Dept of Computer Science Engg.
Guru Nanak Dev Engineering College, Ludhiana, Punjab
Mobile No:- 09855959200
*In your free time kindly visit Sikh-relics.com  -  A Gallery of Blessed Relics of Sikh Guru Sahib
_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Matthijs Melissen | 27 Aug 19:49 2014
Picon

[OSM-dev] Release openstreetmap-carto v2.19.0

Dear all,

Today, v2.19.0 of the openstreetmap-carto stylesheet has been
released. It will be rolled out to the openstreetmap.org servers in
one of the next days.

Changes include:

* Improve rendering of labels of highway areas
(https://github.com/gravitystorm/openstreetmap-carto/pull/865)
* Various bug fixes

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.18.0...v2.19.0.

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues.

-- Matthijs

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Stephan Knauss | 23 Aug 15:08 2014
Picon

[OSM-dev] mod_tile not respecting config value

Hello,

I have a rendering stack with mod_tile/tirex which works quite fine.
Now I discovered that tiles which do not exist at all and take longer to 
render will return a 404 after 3 seconds.

This is surprising to me as I have in apache's mod_tile.conf the 
following settings:

# Timeout before giving up for a tile to be rendered
     ModTileRequestTimeout 3

# Timeout before giving up for a tile to be rendered that is otherwise 
missing
     ModTileMissingRequestTimeout 30

With these setting I would have expected that the timeout is 30 seconds 
for tiles which do not exist at all and be only 3 seconds for requests 
where some older (outdated) tile exists.

I enabled a higher verbosity level and got this in apache logs 
(shortened to the relevant info):

Requesting style(s2) z(7) x(39) y(73) from renderer with priority 5
request_tile: Request xml(s2) z(7) x(39) y(73) could not be rendered in 
3 seconds
tile_storage_hook: Missing tile was not rendered in time. Returning File 
Not Found

So why is mod_tile using a timeout of 3 seconds and not 30 seconds?

More confusing: After I inserted the mentioned two lines into my 
VirtualHost config section which handles the rendering mod_tile is 
working as expected.

Does this indicate that the way global settings are handled by mod_tile 
is broken? Might it indicate that my other settings are not effective as 
well?

Should I open a bug report for it? At GitHub?

Stephan

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Gmane