Re: [OSM-dev] PostgreSQL 11 - osm2pgsql performance problems during --append?

[Sven Geggus]

Michael Kussmaul  wrote:

> - Or PostgreSQL 11 has some regressions?

Unlikely. I'm using PostgreSQL 11 + Debian 10 on my new
tile.openstreetmap.de machines without problems.

Sven

-- 
If we want hardware to work to its full potential, we need to claim to
be a recent version of Windows. (Matthew Garrett)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Rendering OSM carto from epsg:4326 database

[Sven Geggus]

Frederik Ramm  wrote:

> (Or potentially run an update on your existing database the
> re-calculates all the way_area values based on a reprojected polygon.)
> 
> There might be other issues - how exactly does it not work?

I get empty tiles thus I expect a reprojection issue.

Sven

-- 
Threading is a performance hack.
(The Art of Unix Programming by Eric S. Raymond)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Rendering OSM carto from epsg:4326 database

[Sven Geggus]

Hello,

I just got stuck while trying to render osm-carto style from a database
imported epsg:in 4326 format.

I just changed the following:

osm2pgsql: 
  type: "postgis"
  dbname: "gis"
  key_field: ""
  geometry_field: "way"
  extent: "-20037508,-20037508,20037508,20037508"

to

osm2pgsql: 
  type: "postgis"
  dbname: "gis"
  key_field: ""
  geometry_field: "way"
  extent: *world
  srs-name: "WGS84"
  srs: "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"

This does not seem to work.

Will I need to do more?
E.g. change "way" to "ST_transform(way) as way" or something?

Output should still bee in Web Mercator.

Regards

Sven

-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql tile expiry performance

[Sven Geggus]

j  wrote:

> I'm afraid I do not have precise timings, but I'm seeing what appears
> to be at least an order of magnitude performance penalty, probably due
> to memory exhaustion.

I can not confirm this. I have running the new tile Expiry code at least
since December 2017.

As I am about to setup two machines for this purpose right now I reworked
the scritps a bit. They are available here:
https://github.com/giggls/tileserver-scripts

Regards

Sven

-- 
Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das
Verbindungsgebrüll. (aus einer Ebay fishing Mail)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Any problem with Debian tile servers?

[Sven Geggus]

Hello,

I'm also using tirex, not renderd but this is likely a matter of taste:
https://wiki.openstreetmap.org/wiki/Tirex

Usually I'm also using backports of current PostgreSQL when I start with a
new setup. Backporting PostgreSQL 11 is very straight forward.

Regards

Sven

Tom Browder  wrote:
> On Thu, Apr 11, 2019 at 3:24 AM Sven Geggus  
> wrote:
> ...
>> tile.openstreetmap.de is running Debian from day one. So yes, this is
>> working fine.
> 
> Thanks, Sven.
> 
> -Tom
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Any problem with Debian tile servers?

[Sven Geggus]

Tom Browder  wrote:

> I want to run my own tile server but I run Debian 9 on the server I plan to
> use. All the docs I have seen so far target Ubuntu. Is there any problem
> with using other Linux distros?

tile.openstreetmap.de is running Debian from day one. So yes, this is
working fine.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v4.12.0

[Sven Geggus]

Daniel Koć  wrote:

> Today, v4.12.0 of the OpenStreetMap Carto stylesheet (the default
> stylesheet on the OSM website) has been released.

This seems to completely kill my rendering performance.

Will I need additional indexes?

> time render_single_tile.py -s osm.xml -o test-v4.11.0.png -u 
> /15/17090/11446.png
real0m10.586s
user0m0.940s
sys 0m0.304s

> time render_single_tile.py -s osm.xml -o test-v4.12.0.png -u 
> /15/17090/11446.png
real6m52.459s
user0m1.336s
sys 0m0.440s


I'm using Mapnik 3.0.12 and carto 0.18.2. Would I need to upgrade?

Regards

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v4.12.0

[Sven Geggus]

Daniel Koć  wrote:

> Moreover this particular approach to surface rendering has been
> developed for about a year, so I'm surprised you missed the whole
> discussion.

The problem is not with surface rendering but this:

"* code re-ordering - no rendering change"

I just try to manually re-add all my changes to a vanilla v4.12.0 roads.mss 
which
seem to work so far.

Regards

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v4.12.0

[Sven Geggus]

Christoph Hormann  wrote:

> That's a really tough call.

May I mention the fact, that Mapserver is still actively maintained and that
there even is a carto preprocessor called magnacarto which is able to
produce mapserver style files.

Sven

-- 
Freiheit ist immer die Freiheit des Andersdenkenden
(Rosa Luxemburg)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v4.12.0

[Sven Geggus]

Daniel Koć  wrote:

> Changes
> - Added rendering “surface” tag on roads with a pattern

This is not supposed to be a huge change, right?

Are you unaware of the fact that there are forks of OpenStreetMap Carto like
German style which are keept in sync by merging them with every upstream
release?

I'm doing this for German style for more than 2 years now without that much
of a hassle up till this release.

This will now kill my ability to keep on doing this at least as roads.mss is
concerned!

The commit which causes the hassle is most likely this one:

Author: Lukas Sommer 
Date:   Fri May 11 10:57:04 2018 +

Render “surface” tag on roads with a pattern (#2640)

* code re-ordering - no rendering change

* Render unpaved road surface with a pattern

WTF. Did you have a good reason which was worth killing your forks ability to
stay in sync with upstream?

Regards

Sven

-- 
"Whenever there is a conflict between human rights and property
rights, human rights must prevail." (Abraham Lincoln)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Coastline – osm2pgsql

[Sven Geggus]

SandorS  wrote:

> As I understand the two involved processes are independent and the results
> are just mixed together at certain moment during the map-making process.

Right.

The main reason for doing this is, that coastlines tend to be broken very
often. Likely they are broken more often than they are actually usable.

Thus it has been decided a long time ago, that land polygons are rendered from
shapefiles proven to be mostly correct (e.g. all continents do exist) and
up-to-date stuff produced by osm2pgsql.

If you like to render your own map you can easily produse matching data from
the same planet file.

The coastline processing toolchain is available here:
https://github.com/osmcode/osmcoastline

Regards

Sven


-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Advantages PostgreSQL 10.0 + PostGIS 2.4

[Sven Geggus]

Hello,

Debian stable 9.x comes with PostgreSQL 9.6 and Postgis 2.3.

However the now released PostgreSQL 10.0 and Postgis 2.4 are an easy
backport.

Will the newer version provide any advantage for a osm2pgsql database use case?

Sven

-- 
If we want hardware to work to its full potential, we need to claim to
be a recent version of Windows. (Matthew Garrett)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Question regarding Carto 4.x database scheme

[Sven Geggus]

Hello,

looking at the hstore support in Carto 4.x I was wondering if the provided
lua script would work with an hstore-only database as well.

I have been using such a scheme in carto-de for quite a while now and would
like to continue doing so.

osm=> \d planet_osm_hstore_line
 Tabelle »public.planet_osm_hstore_line«
  Spalte  |Typ| Attribute 
--+---+---
 osm_id   | bigint| 
 z_order  | integer   | 
 way_area | real  | 
 tags | hstore| 
 way  | geometry(LineString,3857) | 

Actual rendering is done using views emulating the table layout required by
a given style.

To do a reimport I have to decide if I continue using this table layout or
if I migrate back to a mixed hstore/column based setup as used by Carto 4.x.

Thus, would openstreetmap-carto.lua work with the hstore-only database as
well?

Regards

Sven

-- 
AMZN US won't let me buy MP3s b/c I have UK credit cards. Amazon UK won't   
let me buy MP3s b/c I'm in the US. P2P doesn't care. Go copyright!
(Cory Doctorow)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Questions regarding carto 4.0 release and German style fork

[Sven Geggus]

Hello,

looking at the Openstreetmap Carto 4.0  release I see two major changes
regarding the database layout.

1. We finally have hstore
2. Tags are pre-processed by a lua script.

Is there more which might be relevant for the fork?

Up till know Mapnik German style (an Openstreetmap Carto fork) has been
using an hstore-only database with no sepearte tag columns at all and a
database view emulationg the column based layout.  Upstream style has always
been usable using this approach.

With the recent introduction of hstore in upstream this setup will get more
complicated.  Especially the l10n code is currently dependent on the fact,
that all name tags are present inside the hstore column.

However this can be changed and looks like a manageable approach.

So the question I have to answer for myself now is if it would be worth the
effort working in a direction to be able to use an unchanged database layout
from upstream style.

For this reason I need to know, what the lua script is doing to make shure,
that nothing is processed in a way which will alter the appearance of my
style.

So can somebody please explain in a few words what the lua script is actually
doing?

Sorry, I am neither familiar with lua nor ist osm2pgsql interface.

I suspected it might prevent me from redering mountain paths in a different
way than footways, but as far as I can see this is not the case.

Regards

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v3.0.0

[Sven Geggus]

Christoph Hormann  wrote:

> No, the new project.mml is just a renamed project.yaml.

*argh*

So it would be best to do a git mv project.yaml project.mml before trying to
merge?

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] OpenStreetMap Carto release v3.0.0

[Sven Geggus]

Paul Norman  wrote:

> - Official Tilemill support is dropped

Is this the reason why project.yaml has been removed? Thus project.mml is
now the official style file?

As yaml files are more readable why did you do this?

Unfortunately my german style fork is based on a modified project.yaml not
project.mml (which I always ignored) thus your change will now basically kill 
my fork
because I did not maintain a forked .mml :(

Regards

Sven

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Taginfo files from osm2pgsql style files

[Sven Geggus]

Paul Norman  wrote:

> It's not the most useful utility but there's a chance it might be useful 
> for someone else.

Hm, looks like this does not make that much sense in case of a hstore-only
database like the one I am using in the german style setup.

One should at least pass the "nocolumn" entries to reflect, that these are
considered important tags. Not adding a column does not make them unused.

I think the tool which will generate taginfo json should actually be
added to node-carto rarther than osm2pgsql.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Mukti and Gargi fonts for openstreetmap-carto

[Sven Geggus]

Rory McCann  wrote:

> I'm also having this problem with "Mukti Narrow Bold". I have no problem
> with "gargi Medium", that worked for me on stock Ubuntu 14.04 *shrug*.

Jepp. Debian stable is slightly newer here than 14.04 thus gargi.ttf has
already been removed from fonts-deva-extra in debian stable.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Mukti and Gargi fonts for openstreetmap-carto

[Sven Geggus]

Paul Norman  wrote:

> Something I've found when researching fonts for Asian languages is that 
> the versioning, releases, name consistency, and other releasing 
> engineering matters are often inadequate. Coupled to this, many webpages 
> for fonts disappear after a few years.

Hm so can't we just go for "No Tofu" fonts?

They are supported by Google and are available as a Debian Package:
https://www.google.com/get/noto/
https://packages.debian.org/sid/fonts-noto

However I have no Idea if all of the south asian scripts are covered.

Regards

Sven

-- 
Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Mukti and Gargi fonts for openstreetmap-carto

[Sven Geggus]

Hello,

I'm trying to install all required fonts for openstreetmap-carto on debian
stable.

Two fonts seem to be troublesome:
"Mukti Narrow Bold" and "gargi Medium"

While the former seems to be there
(/usr/share/fonts/truetype/fonts-beng-extra/MuktiNarrowBold.ttf) but is not
found by fc-match -s for some reason, the other one just seems to have gone
from the Debia/Ubuntu repositories. It seems to have been replace by
"Gargi Regular".

Any hint on how to install?

I worked around the gargi font problem by downgrading the fonts-deva-extra
package to 2.0, but I havee no Idea about the Mukti dont.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] cross-fade map sample code (ol3 or leaflet)

[Sven Geggus]

Sven Geggus <li...@fuchsschwanzdomain.de> wrote:

> Jepp. Is there a way to set layer opacity in OL3?

Found the answer myself :)

Opacity can be changed as follows:

layername.setOpacity(x);

With x between 0 and 1.

Done that I am now looking for a way to reload tiles of a given layer.

Sven

-- 
"Das Einzige wovor wir Angst haben müssen ist die Angst selbst"
(Franklin D. Roosevelt)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] cross-fade map sample code (ol3 or leaflet)

[Sven Geggus]

Mattias Dalkvist  wrote:

> The word you are looking for is opacity [1]

Jepp. Is there a way to set layer opacity in OL3?

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] cross-fade map sample code (ol3 or leaflet)

[Sven Geggus]

lars lingner  wrote:

> There are examples for OL3  [1] and for Leaflet [2] and [3].

This is simular, but not exactly what I'm up to. What I actually want is
dissolving layers transparently like in http://sautter.com/map

Sven

P.S.: Looks like the correct word for "überblenden" is dissolve in this case
not fade.

-- 
Freiheit ist immer die Freiheit des Andersdenkenden
(Rosa Luxemburg)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] cross-fade map sample code (ol3 or leaflet)

[Sven Geggus]

Hello,

you probably know http://sautter.com/map/

This is Openlayers 2 code which uses the concept of Base Layers and
Overlays thus this map is kind of an abusing this concept.

I was wondering if there is some sample code for leaflet or Openlayers 3
which will do something like this.

I would need this for the development of an openstreetmap-carto fork to have
an easy way to cross-fade between my fork and the original style from
osm.org

Regards

Sven

-- 
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Updated simplified osm2pgsql database dump available

[Sven Geggus]

Paul Norman  wrote:

> You'd still have the full storage footprint on one machine, it just 
> helps with the requirements on your read-only replica slaves.

Yes,. I imagine that this machine can be run on a central server and peaple
can use this one as a master.

> What is not possible is to centralize this. When doing updates what goes 
> to the rendering tables depends on the osm2pgsql style, so your 
> rendering table updates will not be the same as other people with a 
> different style.

It is possible to centralize this if the database is fairly generic.  I use
hstore-only tables with osm2pgsql all over the place.  The table layout
required by a particular style can the be easily emulated using views.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Updated simplified osm2pgsql database dump available

[Sven Geggus]

Paul Norman  wrote:

> To help with some OpenStreetMap carto development work, I've created a 
> dump of the rendering tables

I have always been wondering if it would be possible to get rid of the
special tables used for the sole purpose of keeping the rendering database
up-to-date by using a scheme like this:

osm2pgsql database with special tables  -> some psql replication scheme

--> many slave databases without special tables kept up-to date using psql
some replication scheme

This would have the advantage of a lower storage foot-print (only 4
rendering tables left).

Frankly, when talking about rendering we don't care about the state of the
upstream OSM database. All we want is to make shure that the rendering
database uses up-to-data data.

Regards

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

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

[Sven Geggus]

Paul Norman  wrote:

> For the osm2pgsql pgsql backend, a polygon is formed when a way is 
> closed and the tag transform sets a polygon flag. If either of these is 
> false, it is a linear feature.

... which is then inserted into planet_osm_line, right?

For some reason I would have expected the feature to be discarded in this
case.

Sven

-- 
Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

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

[Sven Geggus]

Simon Poole  wrote:

> Roundabouts? Or in fact any other way that is closed but clearly a
> linear feature.

I think those are usually not defined as a polygon anyway at least without
area=yes.

So far I have found two types of tags (waterway and aeroway) which will end
up in either planet_osm_polygon or planet_osm_line depending on their
geometry.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

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

[Sven Geggus]

Paul Norman  wrote:

> Assuming it matches some tag with a column, yes. In a case where it has 
> only a key with polygon,nocolumn (or phstore), it wouldn't make it into 
> the line table or polygon table.

This does not seem to be true.

Artificial waterway.osm
--cut--


  
  
  
  
  
  







  

--cut--

Using the following style:

--cut--
node,way   waterway text polygon,nocolumn

node,way   z_order  int4 linear # This is calculated during import
wayway_area real# This is calculated during import
--cut--

Using the following command...

osm2pgsql -S waterway.style -d imposm waterway.osm --hstore --hstore-match-only

... this will end up in a 1 line planet_osm_line table.

Sven

-- 
Exploits and holes are a now a necessary protection against large
corporate interests. (Alan Cox)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] osm2pgsql polygon handling semantic?

[Sven Geggus]

Hello,

looking at the code of osm2pgsql and checking with a hand-crafted .osm file
I came to the conclusion that polygons in osm2pgsql are handled in the
following way:

If a polygon is defined in the .style file a function is called which
generates the simple-feature geometry object.  If this function is unable to
generate a polygon a linestring is created.

Am I right in this assumption?

The reason for this question is that I'm trying to build a imposm3 style
which will create a osm2pgsql compatible database.  This has (among other
things) the obvous advantage, that some additional tables for more exotic
features are easy to create.

Regards

Sven

-- 
Exploits and holes are a now a necessary protection against large
corporate interests. (Alan Cox)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] osm2pgsql: meaning of z_order column in polygon and point tables

[Sven Geggus]

Hello,

I'm currently investigating the capabilities of imposm3 as a drop-in
replacement for osm2pgsql.

The Generation of the z_order column seems to be the only showstopper which
is left to make an imposm3 generated databases suitable for rendering tiles
with the osm standard style.

Unfortunately I have a problem of understanding the generation of the
z_order column for polygon and point tables.

While it seems to be always empty on the point layer and unused in
carto style it seems to be used in the case of polygons.

Looking at the add_z_order function it seems to mostly make sense on roads
only, but it is called in the generation of polygon layers anyway.

My small handcrafted .osm testfile did always add zero to this column which
I nearly expected, as the add_z_order function seems to be mosytly made for
roads.

Am I right in the assumption, that z_order on polygons is only a matter of
the layer tag and could thus be easily emulated using a simple database view
which evaluates tags-'layer' in a hstore column?

Looking at my database seems to confirm this suspicion, but there are also
some occasional apperances of z_order=3 and z_order=5 which seem to be
created mostly unintentially? 

An area tagged railway=station is getting added 5 to the z_order column
only because it is assumed to be a linestring rather than an area?

Same goes for highway areas which are getting added 3 to the z_order column
only because it is assumed to be a linestring rather than an area?

Would be nice if someone could shed a ligth on this.

Regards

Sven

-- 
Exploits and holes are a now a necessary protection against large
corporate interests. (Alan Cox)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] osm2pgsql: Unable to import planet

[Sven Geggus]

Hello,

unfortunately I'm unable to import current planet files using osm2pgsql.
This might be a psql issue because the strange error message I get seems to
come from postgress rather than osm2pgsql:

osm2pgsql -U postgres -s --number-processes=8 -C4000 -S hstore-match-only.style 
--flat-nodes /tmp/flatnodefile --hstore --hstore-match-only -d digmt 
planet-150105.osm.pbf
osm2pgsql SVN version 0.87.1 (64bit id space)

Using built-in tag processing pipeline
Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for dense node cache
Allocating dense node cache in one big chunk
Allocating memory for sparse node cache
Sharing dense sparse
Node-cache: cache=4000MB, maxblocks=512000*8192, allocation method=11
Mid: loading persistent node cache from /tmp/flatnodefile
Allocated space for persistent node cache file
Maximum node in persistent node cache: 0
Mid: pgsql, scale=100 cache=4000
Setting up table: planet_osm_nodes
Setting up table: planet_osm_ways
Setting up table: planet_osm_rels

Reading in file: planet-150105.osm.pbf
Processing: Node(2672693k 1631.7k/s) Way(267143k 7.32k/s) Relation(2297370
57.27/s)Maximum node in persistent node cache: 3270508543
node cache: stored: 499159094(18.68%), storage efficiency: 95.21% (dense
blocks: 463882, sparse nodes: 24636458), hit rate: 13.42%
Osm2pgsql failed due to ERROR: get_way_list failed: FEHLER:  invalid memory 
alloc request size 18446744073709551613
(7)
Arguments were:
{158316322,37669753,156819792,156819720,245694537,156819742,158316324,126760837,95242622,95242612,31404881,158316333,29171707,26142674,37626540,29178874,26202582,29020170,57208434,57208429,26142794,29200328,29200230,293588151,29200312,29070293,24277202,34616458,24277204,61594153,158316940,158316941,158316934,35878683,35147653,57737110,158316942,26963683,57737104,95351513,95351552,95351505,95351547,95351519,95351544,35998299,158316920,158316943,158316935,127949408,35999803,127949407,314868523,124719357,36824502,36887582,158319685,158319677,36826753,119960436,119960555,119960556,158319690,158319678,158319703,39432345,39432346,231742109,42071595,42071598},

Any Idea?

Sven

-- 
linux is evolution, not intelligent design
(Linus Torvalds)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

- End forwarded message -

-- 
linux is evolution, not intelligent design
(Linus Torvalds)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] No more PBF planet files?

[Sven Geggus]

Hello,

looking at the current osm planet file I only find osm.bz2 Versions.

While http://planet.openstreetmap.org/planet/planet-latest.osm.bz2 is
from 2014-12-22
http://planet.openstreetmap.org/pbf/planet-latest.osm.pbf is still
dating back to 2014-12-07

An Idea?

Sven

-- 
Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der
Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der
Demokraten (Theodor W. Adorno)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Release openstreetmap-carto v2.25.0

[Sven Geggus]

Andy Allan gravityst...@gmail.com wrote:

 So I pose a question that's most pressing on my mind - should the
 other maintainers be merging PRs without me reviewing them first? Will
 this lead to a better result?

Hm, with osmarender we already had something like this in the past. Back
then I always hoped that I did not break anything when doing a commit to
openstreetmap svn because it went live automatically on the next update of
tiles@home.

It has arguably always been more ugly than even the mapnik style of that time, 
but it
but tended to be some kind of an all in one Open-street-map.

So probably we should fork and go for two different styles with a different
maintainer model again.

BTW, I'm also still looking for a less annoying way to maintain the german
style which is basically a fork of your style starting from various versions.

Sven

-- 
We just typed make
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] load-osm.sh

[Sven Geggus]

Ilya Zverev i...@zverev.info wrote:

 The solution is obvious: I rented a huge hourly-priced droplet, 
 installed postgresql and osm2pgsql there, imported a big OSM extract, 
 deleted slim tables and transferred database contents to said 
 rendering server.

Jepp. I already did something like this myself. A disadvatage of the
approach is, that there is no way to dump indexes, they have to be
re-created on the target machine while running pg_restore.

Looking at the disk-space overhead needed for slim tables (roughly 1:2) I
also thought about a postgresql only update solution back then.

I still think distributing sql updates for rendering databases in addition
to osm diffs would be a nice to have feature, because the state of the osm
database is of no interest to a rendering database.  I never tried to
implement this though.

Regards

Sven

-- 
TCP/IP: telecommunication protocol for imbibing pilsners
 (Man-page uubp(1C) on Debian/GNU Linux)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Adding Slippy Map to Taginfo's Projects Tab?

[Sven Geggus]

Jochen Topf joc...@remote.org wrote:

 I think a quick-and-dirty 80/20 solution would still be useful. Most projects
 currently supplying data to taginfo do not supply a complete list of tags they
 use either.

+1

A list of the database table columns in use would be something like this.

Sven

-- 
The term any key does not refer to a particular key on the keyboard. It
simply means to strike any one of the keys on your keyboard or handheld
screen. (Compaq FAQ Entry 2859)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Adding Slippy Map to Taginfo's Projects Tab?

[Sven Geggus]

Holger Jeromin mailgm...@katur.de wrote:

 This is the problem. Some of the tags are transformed by an SQL query,
 which is not easy convertable to taginfo.

How about just using the rendering database table or view column names.
While symbols can not be added this way it would at least be a start.

This will of corse not work if the style itself refers to a hstore column.

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] tirex and mapnik 3, make deb fails

[Sven Geggus]

Stephan Knauss o...@stephans-server.de wrote:

 Is a newer build automatically recognized as a newer package?

No, use dch -i 

Regards

Sven

-- 
Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Vector tile based raster rendering - toolchain?architecture

[Sven Geggus]

Frederik Ramm frede...@remote.org wrote:

 I'd be interested to hear your opinions on this.

IMO one of the big advantages of the mod_tile/tirex aproach is that it is in
not bound to use mapnik as a renderer at all.  Using tirex it is currently
possible to use mapserver or any other renderer which is capable to do wms.

An ideal Vector tile solution should IMO preserve this possibility e.g. by
providing a gdal input driver for the vector format in use.

Regards

Sven

-- 
linux is evolution, not intelligent design
(Linus Torvalds)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] New OSM Test Data Repository

[Sven Geggus]

Jochen Topf joc...@remote.org wrote:

 It also depends on what you are testing. If you are testing the OSM XML 
 parser,
 those cases are valid data that the OSM parser must understand. If you are
 testing the renderer, it might be different.

For the renderer it would be nice to have a model village featuring all
objects in the standard mapnik style.

Apart from this I once set up a testfile for verification of correct
rendering of riverwidths. Background: I learnt from a cartographer, that
waterbodies should always be rendered in their real width on the ground.

Probably also of interest to this database.

Regards

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] New OSM Test Data Repository

[Sven Geggus]

Jochen Topf joc...@remote.org wrote:
 I have started to work on a common OSM test data repository that can be
 used to test all sorts of software that works with OSM data.

Hm, you seem to user real osm id-numbers.

Don't you think we should define a private id-range for this purpose?

900 and above might be a reasonable range.

I think about importing such data into postgis for rendering tests and it
might be bad in some cases if this would kill existing data.

Sven

-- 
Those who do not understand Unix are condemned to reinvent it, poorly
(Henry Spencer)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] An alternative rendering-database setup and update strategy!

[Sven Geggus]

Hello,

on my day-job I recently had to solve the Problem of setting up a Postgis
database contaning a full-planet extract using one of those cheap 180GB SSD
on a semi-potent machine (only 8GB of RAM).

I first tried to use osm2pgsql for this purpose which is almost impossible
for a couple of reasons:

* I would have needed more than 180GB of disk space (at least during import)
* The import would take a _very_ long time (several days rather than hours)

So I had to look for a backup strategy!

I found one which proved to be that good, that I would like to discuss it
here as an alternative way for rendering-database setup.

The first thing I discovered is the fact, that we currently use roughly twice
the disk-space for intermediate tables (or file in case of flatnode) than
for the processed data itself.

Here is how this looks like on tile.openstreetmap.de:

 relation  | total_size 
---+
 public.planet_osm_line| 61 GB
 public.planet_osm_polygon | 59 GB
 public.planet_osm_point   | 10 GB
 public.planet_osm_roads   |  8 GB

 public.planet_osm_ways| 174 GB
 public.planet_osm_rels|   4 GB

+ flatnode.dat 20 GB

processed data: 61GB+59GB+10GB+8GB=138GB
intermediate data: 20GB+174GB+4GB=202GB

The most annoying part is the 174GB planet_osm_ways table.

So what I did to solve my problem was using pg_dump for the processed data
tables only and setting up my target database using pg_restore.

Advantages:
* Very fast data import even on machines where import using osm2pgsql would
  be practically impossible
* Decent size of database dump (32GB in case of a --hstore-match-only database
  which is about the same size as a planet dump)

Disadvantages:
* Currently no update strategy available
* Will need a master osm2pgsql database
* Will inherit table scheme from master database

Conclusion:

IMO the disadvantages can be resolved or at least mitigated in the following
way:

* we generate a downloadable dump of the database on
  tile.openstreetmap.de (e.g. weekly)
* osm2pgsql needs to be patched to output the changes to the processed data
  tables as SQL commands which can then be used to replicated the slave 
databases
* We already use --hstore-match-only database format. So flexibility in
  table-layout is not that much of a concern as views to hstore column can be 
used
  for rendering instead of tables.

I would like to hear your comments to this proposial.

Regards

Sven

-- 
Threading is a performance hack.
(The Art of Unix Programming by Eric S. Raymond)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web


-- 
Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] My Openstreetmap style localization howto

[Sven Geggus]

Hello,

I just wrote the missing documentation about how I did the
localization of the german Tileserver.

Probably of interest to people from other countries speaking
languages written in latin script:

http://blog.gegg.us/2013/09/a-simple-way-to-localize-latinize-an-openstreetmap-style/

Regards

Sven

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osmcoastline install question

[Sven Geggus]

Jochen Topf joc...@remote.org wrote:

 The osmcoastline README mentions the ubuntugis repository. Yes, it could
 probably be made clearer how to install this, but then I'd have to explain
 it for each and every distribution.

I will second this. There are people (like me) which do not like to use
Ubuntu for a couple of resons.

 Adding extra repositories is a rather drastic step, it is done differently
 in different distributions and it is not necessary in all distributions.

E.g. not necessary for Debian stable.

 This should not be necessary. Older versions of boost are fine.

Works fine using libboost1.49-dev on debian stable.

What you should probably add to teh README is the Number of Warnings and
errors issued by a correct run of runtest.sh.

Sven

-- 
Whenever there is a conflict between human rights and property
rights, human rights must prevail. (Abraham Lincoln)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Changing language in tile server

[Sven Geggus]

Gurpinder Chahal chahalgurpinde...@gmail.com wrote:

 I'm trying to change language in my OSM tile server.
 I have modified my fontset-settings.xml.inc and osm.xml. But these
 things didn't worked. These just gave rectangular boxes on my map.

Can you describe in more detail what you tried to do?

I have l10n stuff in our german mapnik style (the one used at
http://openstreetmap.de/karte.html) which can be also used for
any other languages using latin script (french, spanish, ..)

You will basically need the following:
* separate colums in database for int_name, name:en, name:yourlang
  or hstore (which is what I recomend).
* replacement of all select name by select 
yourfunc(name,int_name,name:en,name:yourlang) as name
* PL/pgSQL function from 
http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/get_localized_name.sql
* optional Transliteration code is here:
  
http://svn.openstreetmap.org/applications/rendering/mapnik-german/utf8translit/

Our get_localized_name function can be used for any language using latin
script. If you e.g. want to prefer spanish use it like this:

get_germanified_name(name,name:es,int_name,name:en) as name

name:en is used as an alterative to int_name in case name is not latin
script.

Known issues with transliteration currently are:
* Thai Language uses ISO 11940 rather than RTGS
* Kanji Transliteration produces chinese rather than japanese

Regards

Sven

P.S.: Minimal (sorry) documentation of the i10n stuff is here:
http://svn.openstreetmap.org/applications/rendering/mapnik-german/README.i10n
http://svn.openstreetmap.org/applications/rendering/mapnik-german/utf8translit/README

-- 
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
 die anderen sind einfach von sich aus unlogisch.
  (Anselm Lingnau in de.comp.os.unix.discussion)
/me ist giggls@ircnet, http://sven.gegg.us/ im WWW

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

Re: [OSM-dev] Bug in OSM.org map stylesheet? Text partially missing...

[Sven Geggus]

Manuel Reimer manuel.s...@nurfuerspam.de wrote:

 So for me it seems to be a bug somewhere in Mapnik.

This is a tile edge artifact. Same on german style:

http://www.openstreetmap.de/karte.html?lat=49.959186lon=9.656336zoom=18

Same Problem as with our Autobahn signs:
http://www.openstreetmap.de/karte.html?lat=48.94792lon=8.4373zoom=11layers=B000TT

Sven

-- 
Dynamische IP-Nummern sind Security-Homöopathie.
(Kristian Köhntopp)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] disk size for planet osm import into PostGIS (on an SSD)?

[Sven Geggus]

Frederik Ramm frede...@remote.org wrote:

 and use a stripped style.xml 

I assume you meant osm2pgsql style.

 that ensures you don't store tons and tons of note and source tags and
 other import side products. You don't want to burden your SSD with tags
 like gnis:Class, NHD:FType, tiger:PCICBSA, or canvec:UUID ;)

Here is the one we use on the german tileserver:
http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/default.style

Sven

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile on windows?

[Sven Geggus]

Vince Berubey scream...@hotmail.com wrote:

 Has any development been done since to be compatible with Windows?

Besides the fact that I do not see a particular good reason for running a
tileserver on windows (mapnik works fine on windows, so style development
can already take place on windows), I seriously doubt, that this will
currently work.

One reason for this is, that mod_tile uses a unix-domain socket to
communicate with the backend (tirex/renderd). So one would need at least
convert this to a tcp/socket.

IMO, there is better work to do for mod_tile. One thing that comes to mind
is the still unimplemented whitelist feature for tile trotteling, which I
would have needed recently.

This said I'm quite certain that Kai would not mind to take patches which
will actaually make it work on windows. It's free software after all.

Regards

Sven

P.S.: In this live I will probably not understand anymore, why people
actually _want_ to use windows. Bad enough, that one is still forced to use
it way to often.

-- 
Those who do not understand Unix are condemned to reinvent it, poorly
(Henry Spencer)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Generate tiles with generate_tiles.py

[Sven Geggus]

Vince Berubey scream...@hotmail.com wrote:

 For example, I download an .osm.bz2  from Cloudmade, the map of
 Ile-De-France=Paris
 http://downloads.cloudmade.com/europe/western_europe/france/ile-de-france#downloads_breadcrumbs
 I would like to call generate_tyles.py from another language. I want to
 pass the bounding box values as arguments, but I don't want to go in the
 Import Tab of OpenStreetMap and manually select the area.

Are you rendering directly from the osm file or do you import the data to
postgis? If so you can get the bounding box of all data from postgis using
ST_Envelope.

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] mod_tile causes segfault on debian 7.0

[Sven Geggus]

Hello,

I have massive trouble running a recent version of mod_tile (git commit
03dedd4ec33c9d5e6495ea54d8a36b4ad916f65b) with my usual tirex backend.

I get segmentation faults in mod_tile on a more or less regular basis which
will leave apache in a 100% CPU on all cores state!

[248792.019396] traps: apache2[21353] general protection ip:7f259cb3e329 
sp:7f25904bca10 error:0
[248792.019405] traps: apache2[21388] general protection ip:7f259cb3e329 
sp:7f2588cada10 error:0
[248792.019414] apache2[21390]: segfault at 0 ip 7f259928f919 sp 
7f25884acae0 error 4
[248792.019424]  in libapr-1.so.0.4.6[7f259cb2b000+38000]
[248792.019589]  in mod_tile.so[7f2599288000+13000]
[248792.021397]  in libapr-1.so.0.4.6[7f259cb2b000+38000]
[248794.024127] apache2[21436]: segfault at 6cf83c57 ip 6cf83c57 sp 
7f258ccb5c28 error 14

The commit message of 59f1ac181ad43747d6f641dfce21c0f922eb2885 looks
suspicious to me:

Unfortunately there is no way to do this in Apache 2.2. So there you will
need to use mpm prefork for non thread safe backends.

I _do_ run apache 2.2 (which is still standard for debian 7.0) and I do use
apache2-mpm-worker because of performance reasons. This has been working
fine for a long time on tile.openstreetmap.de using Debian oldstable.

Will this stuff be relevant to me at all, because I'm using tirex as a backend.

Looks like I need to go back to an older version of about one year ago or so
:(

Regards

Sven

-- 
# Turn on/off security.  Off is currently the default
(found in MongoDB default configfile)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile causes segfault on debian 7.0

[Sven Geggus]

Andy Allan schrieb am Mittwoch, den 22. Mai um 13:34 Uhr:

 Ah, that's interesting, I'm seeing something very similar. I'm using
 1341e129e5 (22 April) with apache2-mpm-event 2.2.22 (on Ubuntu 12.04)

Debian stable is also using apache 2.2.22 (with apache2-mpm-worker in my
case).

 I'm not sure what's triggering it, but it looks like it might be
 happening every few days. 

Same behaviour here and this does not seem to be load related.

Sven

-- 
Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das
Verbindungsgebrüll. (aus einer Ebay fishing Mail)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] lua+osm2pgsql=?

[Sven Geggus]

Kai Krueger kakrue...@gmail.com wrote:

 The question now is what to do with this? Is there enough interest for it to
 be worth cleaning it up and committing it?

I once did a somewhat ugly hardcoded hack for converting width and height
tags to useful floating point values by doing a lot of heuristics
(output-pgsql.c line 460ff.)

Am I right in the asumption, that we can get rid at least of parts of
this as well using your code?

Sven

-- 
Why are there so many Unix-haters-handbooks and not even one
Microsoft-Windows-haters handbook?
Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf!
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql: support for local route names

[Sven Geggus]

Kai Krueger kakrue...@gmail.com wrote:

 So name:de and name:fr are already available in the standard osm2pgsql db.
 Also all other tags of the route relation are in the db. Why osm2pgsql
 translates the name tag into route_name, I don't know. Also I wonder why
 there is so much special casing of various ncn, rcn, lcn cycle relations?

All this stuff predates hstore support.

Sven

-- 
Dynamische IP-Nummern sind Security-Homöopathie.
(Kristian Köhntopp)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] tirex: Can't locate mapscript.pm

[Sven Geggus]

Marcus Kruse kr...@vivai.de wrote:

 where can I find the mapscript.pm?

Hm, are you trying to manually build tirex? You should really build a
package instead using dpkg-buildpackage (at least on Debian and Ubuntu).

The required perl dependencies can be found in debian/control

back to your question. mapscript.pm is the mapserver perl Interface thus
this is only necessary for the mapserver backend.

On Debian/Ubuntu the package which contains mapscript.pm is called
libmapscript-perl

Regards

Sven

-- 
If you can spend five minutes on the Internet and do not run Linux,
you're a genius. (Dirk Hohndel)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql: support for local route names

[Sven Geggus]

RainerU ra...@sfr.fr wrote:

 As it works fine and the risk of regression or side effects seems very low
 to me, I propose to include this feature into the repository. Do the
 maintainers of osm2pgsql agree?

Wouldnt it make more sense to copy all tags probably prefixing route_ to be
compatible to the existing code?

Sven

-- 
Dynamische IP-Nummern sind Security-Homöopathie.
(Kristian Köhntopp)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile stable version ?

[Sven Geggus]

Sarah Hoffmann lon...@denofr.de wrote:

 I'd be very happy to see you step up as maintainer and move the stuff
 to github. I'd feel much more comfortable to submit pull requests to 
 github instead of doing direct SVN commits that nobody even knows 
 about unless the code fails in some annoying way.

I oppose the Idea of moving our software to a commercial platform
(github) but I agree to the rest of your post.

I always have a somewhat uncertain feeling about horribly breaking
something when doing direct commits to osm2pgsql, as I know that
there are people using its single existing trunk version for
production systems.

IMO the real problem is not about tools (git vs. svn) but rather about
a missing concept of how the software is maintained.

Git tends to enforce policy in our context only because we don't have software
maintenance at all.

Sven

-- 
Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] announcing a new mailinglist tile-serving

[Sven Geggus]

Simone Cortesi sim...@cortesi.com wrote:

 having two or more styles based on the same data. this is something I
 believe tirex will allow me to do.

IMO the main advantage of tirex is its independance of render
backends. While renderd intermixes actual rendering and queue
management tirex uses different jobs for this.

Thus one can easily run a tileserver where one style is based
on mapnik while the other one is based on umn mapserver instead.

Regards

Sven

-- 
The main thing to note is that when you choose open source you don't
get a Windows operating system.
  (from http://www.dell.com/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile stable version ?

[Sven Geggus]

Jochen Topf joc...@remote.org wrote:

 Frederik uses Tirex and it works reliable for him

As do I on tile.openstreetmap.de. NOP is also using Tirex on
wanderreitkarte.de

 This is only solved by somebody taking up the torch and running with it.

Jepp!

I currently have a small patch for osm2pgsql here and I don't know what to
do with it.

As there is no official maintainer I can only do two things keep it for me
or just commit it. This is not a big risk in this case, but I would rather
like to ask for an OK first, but whoom should I ask?

Sven

-- 
If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops (Tim Berners-Lee)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile stable version ?

[Sven Geggus]

Bernard Fouché bernard.fou...@kuantic.com wrote:

 My time was mostly spent because of the lack of stable releases and 
 documentation related to package versions, quirks here and there (for 
 instance when making Tirex there is no check of what perl packages are 
 already available

Hm, this is at least kind of a distro problem. If debian packages are build
the required packages are installed automatically via dependencies.

Sven

-- 
Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile stable version ?

[Sven Geggus]

Bernard Fouché bernard.fou...@kuantic.com wrote:

 - but I have crashes with renderd with what's currently available on the 
 SVN repo

Frustration about renderd was the main reason why tirex was born a few years
ago.

So you will probably give it a try instead of renderd.

https://trac.openstreetmap.org/browser/applications/utils/tirex

Regards

Sven

-- 
Das Einzige wovor wir Angst haben müssen ist die Angst selbst
(Franklin D. Roosevelt)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] mod_tile stable version ?

[Sven Geggus]

Bernard Fouché bernard.fou...@kuantic.com wrote:

 Tirex compilation completed, now I'm battling to understand where to fix 
 a mysterious renderer internal error  generated by 
 tirex-backend-manager: I have mod_tile talking to tirex-master, the 
 back-end manager sees the requests and then takes some time before 
 failing with this message for each tile to generate.

Both, tirex-master and tirex-backend-manager can be run in foreground in
debug mode (-d) which is very helpful. And then there is tirex-status, which
is also a very helpful tool (of course only after tirex is already running).

Sven

-- 
linux is evolution, not intelligent design
(Linus Torvalds)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql way_area is 0 for small areas

[Sven Geggus]

Michael Kussmaul kussmaul.l...@nix.ch wrote:

 I'm using osm2pgsql in hstore+latlon configuration and experienced a
 problem with the calculated way_area. For small areas (parks, buildings)
 the value stored in the database is always 0. Looking at the code
 output_pgsql.c (line 931, 1162, 1215), I saw we simply use %f to format
 the calculated area - obviously this results in a rounded 0.00 for
 very small areas.

I consider this to be a bug.

 I was wondering if there would be any side-effects in OSM toolchains if we
 change this to an %g formatter?

I don't think so because psql is the only software affected by this change.

 This would enable exponential notation for very small numbers (e.g.
 1e-10) - do you think this will break existing software? I changed
 osm2pgsql localy to use the %g formatter for my usecase - but I would be
 grateful if such a change could be incorporated into mainstream, so I do
 not need to patch the file for every update. What do you think?

I would just commit the change to svn.

 My other question would be: How could I disable way_area calculation in a
 hstore configuration? I understand I can add way_area in a normal
 default.style config file, but when using a hstore.style, I was not
 capable of disabling the calculation of the way_area.

This will arise from the fact, that way_area is an artificial tag. Normal
tags can be disabled easily by style-file options.

The way this works is that the key/value combination will be ignored right
away, when data is read from the osm/pbf file. As this can not work this way
with an artificial tag I would suggest something like the following patch:

Index: output-pgsql.c
===
--- output-pgsql.c  (revision 29383)
+++ output-pgsql.c  (working copy)
@@ -44,6 +44,8 @@
 t_point, t_line, t_poly, t_roads
 };
 
+static int enable_way_area=1;
+
 static const struct output_options *Options;
 
 /* Tables to output */
@@ -193,6 +195,10 @@
 exit_nicely();
 }
 
+if ((0==strcmp(temp.name,way_area))  (temp.flags==FLAG_DELETE)) {
+enable_way_area=0;
+}
+
 temp.count = 0;
 /*printf(%s %s %d %d\n, temp.name, temp.type, temp.polygon, offset 
); */
 
@@ -925,7 +931,7 @@
 if (!strncmp(wkt, POLYGON, strlen(POLYGON)) || !strncmp(wkt, 
MULTIPOLYGON, strlen(MULTIPOLYGON))) {
 expire_tiles_from_nodes_poly(nodes, count, id);
 area = get_area(i);
-if (area  0.0) {
+if ((area  0.0)  enable_way_area) {
 char tmp[32];
 snprintf(tmp, sizeof(tmp), %f, area);
 addItem(tags, way_area, tmp, 0);
@@ -1156,7 +1162,7 @@
 /* FIXME: there should be a better way to detect polygons */
 if (!strncmp(wkt, POLYGON, strlen(POLYGON)) || !strncmp(wkt, 
MULTIPOLYGON, strlen(MULTIPOLYGON))) {
 double area = get_area(i);
-if (area  0.0) {
+if ((area  0.0)  enable_way_area) {
 char tmp[32];
 snprintf(tmp, sizeof(tmp), %f, area);
 addItem(tags, way_area, tmp, 0);
@@ -1209,7 +1215,7 @@
 /* FIXME: there should be a better way to detect polygons */
 if (!strncmp(wkt, POLYGON, strlen(POLYGON)) || 
!strncmp(wkt, MULTIPOLYGON, strlen(MULTIPOLYGON))) {
 double area = get_area(i);
-if (area  0.0) {
+if ((area  0.0)  enable_way_area) {
 char tmp[32];
 snprintf(tmp, sizeof(tmp), %f, area);
 addItem(tags, way_area, tmp, 0);

Sven

-- 
Unix is simple and coherent, but it takes a genius – or at any rate a
programmer – to understand and appreciate the simplicity
(Dennis M. Ritchie)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web


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

Re: [OSM-dev] Getting lat and long from an address

[Sven Geggus]

drugdu fjb.pa...@gmail.com wrote:
 I’m trying develop an desktop application  to get the lat and long base on an
 address, the problem is that I must do this offline, I tried to export the
 map, but I need all my county and the export tab says that I need to choose
 a smaller area, it’s my first time working with maps and I really don’t have
 any idea where I can start to learning about this,

Have a look at http://download.geofabrik.de/

Sven

-- 
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Zeroing or Extending a Hillshade-Tiff

[Sven Geggus]

Peter Körner osm-li...@mazdermind.de wrote:

 what way would you choose and wich tools could be used to go that way?

Use the Water-Polygons from openstreetmapdata.com instead of land
polygons.

This way you can use a layer order like this:
* gray background
* hillshade
* water polygons without opacity

Regards

Sven

-- 
In my opinion MS is a lot better at making money than it is at making good
operating systems (Linus Torvalds, August 1997)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Reminder: Node 32-bit exhaustion

[Sven Geggus]

Andrew M. Bishop a...@gedanken.demon.co.uk wrote:

 If using the standard toolchain of osm2psql, postgresql and mapnik
 what is the minimum software versions that are needed to continue
 creating maps after ids reach 2^31-1?

osm2pgsql supports 64bit id space already for a long time. But since this is
a build-time option the default has been changed to 64bit id space not that
long ago )see svn log for exact date).

As far as mapnik is concerned 2.1 did already work well using osm2psql in 64
bit id mode.

Sven

-- 
Whenever there is a conflict between human rights and property
rights, human rights must prevail. (Abraham Lincoln)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Reminder: Node 32-bit exhaustion

[Sven Geggus]

Stephan Knauss o...@stephans-server.de wrote:

 How do I find out how many bits my server OS has?

A portable ANSI C code for bitsize detection would be this one:

#include stdio.h
#include stdint.h

int main() {
  printf(%d\n,8*sizeof(uintptr_t));
  return(0);
}

I'm using the size of an unsigned integer pointer because this is the one
used for memory access.

Sven

-- 
Whenever there is a conflict between human rights and property
rights, human rights must prevail. (Abraham Lincoln)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] How to make osm2pgsql quiet?

[Sven Geggus]

Svavar Kjarrval sva...@kjarrval.is wrote:

 I was wondering what methods you use to make osm2pgsql be quiet when run
 by crontab.

Why calling it directly instead calling a wrapper script?

At least if you go for incremental updates you need to run a wrapper
script anyway because this will also involve calling osmosis.

The relevant part of our script replicate-loop.sh on the german
tileserver looks like this:

--cut--
#!/bin/sh
...
osm2pgsql ...  /path/to/logfile/osm2pgsql.stdout 
2/path/to/logfile/osm2pgsql.stderr
...
--cut--

Regards

Sven

-- 
Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der
Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der
Demokraten (Theodor W. Adorno)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] installing Osmium on ubuntu 11.10

[Sven Geggus]

Martin Alegre tin.ale...@gmail.com wrote:

 I'm not sure what I did wrong and therefore any feedback is happily
 welcomed!

Did you look at the readme?

--cut--
PREREQUISITES
-
...
OSMPBF (for PBF support)
https://github.com/scrosby/OSM-binary
You need to build this first.
--cut--

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Status of the Mapnik stylesheets

[Sven Geggus]

Lennard l...@xs4all.nl wrote:

 This requires a reload of the database to at least get 
 public_transport=* in.

To get a little bit more flexibility which such stuff we now use hstore and
views on the german-style tileserver.

The overhead is acceptable when using --hstore-match-only

Our views ans the osm2pgsql style-file is compatible with the standard
mapnik style and available here:
http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/

Regards

Sven

-- 
Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Switch osm2pgsql to 64 bit mode

[Sven Geggus]

mar...@gmx.eu wrote:

 Oh, I see. Is there any chance you might update it for the previous
 (and still supported) LTS 10.04?  Unfortunately I cannot update to
 12.04.  at present.  :-(

Just compile osm2pqsql yourself from svn version. That's what I always
do and it is is not that complicated (at least on linux) after all.

Sven

-- 
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety (Benjamin Franklin)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

[Sven Geggus]

Even Rouault even.roua...@mines-paris.org wrote:

 Testing with larger areas, like whole France or Europe, shows sluggish 
 performance when ways are built from nodes, but that's perhaps expected. I 
 didn't compare with other tools to know if the indexing or request strategy 
 is 
 particularly bad.

Hm, would it be possible with this to e.g. convert all the forests
from a complete planetfile to a polygon shapefile while discarding
all the rest?

Sven

-- 
The term any key does not refer to a particular key on the keyboard. It
simply means to strike any one of the keys on your keyboard or handheld
screen. (Compaq FAQ Entry 2859)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2psql .style file parameters/values

[Sven Geggus]

mick bare...@tpg.com.au wrote:

 osm2pgsql does a decent job as far as _I_ can use it, the style file looks
 to me like it should be able to refine things more with different data
 types, eg. boolean, short int, int, long int, float,...

No! In osm2pgsql tags are always assumed to be text which is of course what
they actually are. The z_order int4 and and way_area real are calculated
during import so the do not count.

I did however add support for real columns in february in order to be able
to import width and ele tags as floating point values.

This currently involves a lot of hard coded heuristics!

Here is what it do:
* assume , to be a decimal mark which need to be replaced by .
* take the leading number if there is more than one or additional text
* average if it's a-b
* assume values to be in meters thus ignore any unit but feet
* convert feet to meters if ft is given as unit (1 foot = 0.3048 meters)
* reject anything else


Regards


Sven

-- 
Remember, democracy never lasts long. It soon wastes itself,
exhausts and murders itself. There never was a democracy yet
that did not commit suicide. (John Quincy Adams)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

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

[Sven Geggus]

Frederik Ramm frede...@remote.org wrote:

 Your thoughts on these options - are there more than these three, 
 perhaps? - would be most welcome.

Hm, I consider this to be a renderer rather than a stylefile issue.

On Mapserver (which is unpopular in the OSM world for some reason)
there is are two options for this: RESOLUTION and DEFRESOLUTION.

Imagine you have a Style designed for desktop screens like most styles and
you want to go for a 200 DPI Output resolution you can simply put the
following into a mapfile:

RESOLUTION 200
DEFRESOLUTION 96 (defaults to 72)

http://mapserver.org/mapfile/symbology/construction.html#symbol-units

I think something like this should also be implemented in Mapnik, at least
in the long run.

Regards

Sven

-- 
A strategy for rewarding artists that regulates 'copies' makes as much sense
in the digital age as a strategy for controlling greenhouse gases that
regulates breathing. (Lawrence Lessig)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Origin of shoreline_300.tar.bz2

[Sven Geggus]

Hello,

looks like shoreline_300.shp is somewhat broken:

http://www.openstreetmap.org/?lat=25.387lon=56.27zoom=9layers=M

Where does this data originate from? Is this a simplifierd Version from
processed_p?

Probably it would be possible to re-tile it.

Regards

Sven

-- 
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql - COPY_END SSL error?

[Sven Geggus]

Ákos Maróy a...@maroy.hu wrote:

 the command I used for the import was:
 
 /usr/local/bin/osm2pgsql -d osm -U osm -W -H localhost -S
 /usr/local/share/osm2pgsql/default.style -G -v -m -s -k -K -C 2048
 europe-120525.osm.bz2

On Unix -H localhost does not make sence as does SSL because local access
using unix domain sockets should be much faster and encryption is not needed
on localhost.

Try again with a small OSM file (e.g. downloaded via API) and
without the -H localhost option.

Sven

-- 
Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] A few coastline related questions

[Sven Geggus]

Preet prismatic.proj...@gmail.com wrote:

 * without splitting up of polys into tiles

Are you shure that you want an unsplitted europe-asia-afrika?

 Both of these process planet.osm.pbf, which sometimes needs a 64bit
 machine with a certain amount of ram etc, depending on what exactly the
 tool is doing. I have an older computer with 2gb of ram... Would it be
 possible for me to use either of these tools?

You don't need a full Planet. Just the coastlines are sufficient.

These can be extracted from the planet using osmcoastline_extract from
Jochens toolchain.   
 
Sven

-- 
Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das
Verbindungsgebrüll. (aus einer Ebay fishing Mail)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql invalid polygons

[Sven Geggus]

Ramas ies...@ramuno.lt wrote:

 From user point this relation is correct but from geos point - not.

Whatever your definition of OK may be. The Problem with multipolygons in
their current form ist that there is no definition of a correct
multipolygon AFAIK.

As far as your Example is concerned this is (at least) marked as broken in OSM
Inspektor:

http://tools.geofabrik.de/osmi/?view=multipolygonlon=25.95446lat=55.55431zoom=18overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes


Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql invalid polygons

[Sven Geggus]

Ramas ies...@ramuno.lt wrote:

 how do you solve problem with skipped invalid polygons? 

Fix it in the osm database?

 with error:
 Self-intersection at or near point 2889220.240002 7470212.12

This does not look as a valid polygon to me at leadt in OGC Simple
Features terms.  This could arguably get fixed in osm2pgsql code
because it is know how it is meant to be in this case, but it is not
a valid OGC Simple Features polygon.

Just add an additional way around 160596899 and 160596916 and declare
this one of type inner.

 I patched osm2pgsql and it allows to import such polygons. Mapnik renders
 it correctly. 

Not a good Idea IMO because there is more than Mapnik and quite a lot
of the spatial operations in postgis will not work with invalid
geometries.

Does we need such validations?

I definitely think we do. If osm2pgsql does import and render invalid
polygons they will never get fixes in the database.

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Coastline by Name

[Sven Geggus]

Peter Körner osm-li...@mazdermind.de wrote:

 I was looking for Coastline-Polygons by Country-Name, that would be the 
 coastline intersected with the administrative border and saved under 
 that name.
 
 Before I start to build that on myself I'd like to ask if there's 
 already Code to do that.

Don't know about a tool which extracts administrative borders,
but Jochens new osmcoastline tool is very nice:
git://github.com/joto/osmcoastline/

Importing both, administrative borders and coastlines into postgis and
running ST_Difference  may do the job.

Sven

-- 
In the land of the brave and the free, we defend our freedom
with the GNU GPL (Richard M. Stallman on www.gnu.org)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] hacking outdoor GPS devices

[Sven Geggus]

Mitja Kleider schrieb am Montag, den 16. April um 20:26 Uhr:

 * Are you satisfied with the available devices?

No! They are either not really usable for outdoor stuff (Smartphones even
true for Motorola DEFY) or use proprietary firmware which can not be hacked
(Garmin devices)

 What would you change first?

As far as Garmin Outdoor devices are concerned there are a couple of
usability issues in the current firmware. And there is no bicycle capable
routing algo. Probably it would be possible to integrate monav routing
daemon or osrm.

 * If there was a device with open source firmware, would that be an
 important feature?

The feature would be a extendable firmware. I think it would not matter
that much if the underlying os would be Open Source like in Android or just
hackable using a API like in iOS or Windows Mobile.

 * Why would you but an outdoor GPS anyway instead of using your smartphone?

Still because of the typical Outdoor features:
* daylight capable display (e.g. like in garmin GPSmap devices)
* long lasting battery
* good GPS reception

I think the best hypothetical device for a bicycle handlebar would an Open
Source one connectable to the Internet via Smartphone in the pocket of the
driver of course als replacing a legacy bicycle computer.

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] converting mod-tile dir to flat files?

[Sven Geggus]

Hello,

I have a local mod-tile+ tirex installation running on my desktop at
home.

Now to publish this tiles on a machine without mod-tile I would like
to convert this stuff to a flat file layout z/x/y.png

I already found convert_meta which will produce the required png
files but not the z/x/y directory layout.

What is the magic with this? How can I convert something like
11/0/0/66/61/112.png

Sven

-- 
Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] converting mod-tile dir to flat files?

[Sven Geggus]

Stefan de Konink ste...@konink.de wrote:

 So nothing 'on the fly'? Only postprocessed?

Yes.

Sven

-- 
If you continue running Windows, your system may become unstable.
(Windows 95 BSOD)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year

[Sven Geggus]

Frederik Ramm frede...@remote.org wrote:

 Software processing OSM data will need to either use unsigned integers 
 (which can be problematic in cases where negative values are also 
 required), or switch to 64bit integers altogether.

Or used for other purposes like in osm2pgsql. Will the upcoming licence
change add a delay to this problem?

Sven

-- 
We just typed make
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Licence of the Mapnik style?

[Sven Geggus]

Hello altogether,

with the upcoming adoption of the ODBL for OSM data the licence of common
Mapnik styles will definitely get more important!

I strongly feel the need of a decent map style to be distributed under a
copyleft style licence (IMO Affero GPL would be best suited, but IANAL) to
make shure that any future enhancements will also be freely available.

Currently the licence of a lot of stuff hosted at
http://svn.openstreetmap.org/ including the current mapnik style seems to be
unclear.

The reason why I come up with this question now is that I recently took over
maintenance of the german style (converting it to mapnik2) which started as
a derivative of the international style. Starting from the changes I made I
would like to distribute this style under the terms of the Affero GPL, but I
can not do this without knowledge about the licence of the international
style.


Regards

Sven

-- 
The term any key does not refer to a particular key on the keyboard. It
simply means to strike any one of the keys on your keyboard or handheld
screen. (Compaq FAQ Entry 2859)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Licence of the Mapnik style?

[Sven Geggus]

Richard Fairhurst rich...@systemed.net wrote:

 The shields are mine, and I think the core highway colours (motorway, trunk,
 primary, secondary) might be too, and I'm happy to see them go under WTFPL.
 (But, AGPL, ugh.)

The reason why I have been thinking about AGPL ist that Mapnik stuff is
usually deployed as a webservice and what I would like to achieve is the
following:

If somebody takes the style and runs a derived style on his own
tileserver his changes should be contributed back to the project (IMO).


Regards

Sven

-- 
If you can spend five minutes on the Internet and do not run Linux,
you're a genius. (Dirk Hohndel)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Licence of the Mapnik style?

[Sven Geggus]

Komяpa m...@komzpa.net wrote:

 If mapnik sytlesheet will become AGPL we'll have to get rid of our
 local instance, just to make sure our stylesheet won't be affected.

I have not been talking about changing the (unknown) licence of the original
mapnik stylesheet but of our germanstyle which is a derivative.

I'm certainly not willing to invest any time in some public domain thing
which anybody could just use and fork into a proprietary version.

Probably there is a better copyleft type licence than AGPL for this kind of
stuff.

 Too viral licenses are hard to deal with and should really be avoided
 unless you've got a really really good reason.

Hm, I did not intend to start a BSD vs. GPL Flamewar :(

People are already doing bussiness using proprietary styles (e.g.
http://francetopo.fr/) which is fine for me as long as they do not include
my own work.

Sven

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Licence of the Mapnik style?

[Sven Geggus]

Cartinus carti...@xs4all.nl wrote:

 That would already be achieved with GPL. You don't need AGPL for that.

You might be right. Given that the analogy is as follows:
(mapnik=compiler, stylefile=sourcecode, tile=binary)

Distributing tiles without stylefile would be like distributing
binaries without sourcecode.

Sven

-- 
Remember, democracy never lasts long. It soon wastes itself,
exhausts and murders itself. There never was a democracy yet
that did not commit suicide. (John Quincy Adams)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] different rendering with mapnik based on area?

[Sven Geggus]

Peter Körner osm-li...@mazdermind.de wrote:

 Choose whichever way fits your needs best - and tell us about.

The question is how Mapquest is actually doing it?

Regards

Sven

-- 
Every time you use Google, you're using a Linux machine
 (Chris DiBona, a programs manager for Google)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] different rendering with mapnik based on area?

[Sven Geggus]

Hi there,

is it possible to have different rendering rules based on the area
where rendring takes place using an ordinary mapnik rendering stack
(osm2pgsql+mod_tile+tirex)?

What I would like to do (for now) is implementing a name rendering
logic for the german mapnik style:

name outside europe: coalesce(name:de,int_name,name) 
name inside europe:  coalesce(name:de,name,int_name)

A rough bounding box around europe would be good enough for this
purpose.

Sven

-- 
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql patch for nested relations

[Sven Geggus]

Darafei Praliaskouski m...@komzpa.net wrote:

 I am not using route= relations in osm2pgsql. Is there a way to skip their 
 processing, to get more speed than 4 relations/sec?

You could just skip the code following if( strcmp(type, route) == 0 ) in
output-pgsql.c, but I doubt that this will increase your processing speed
significantly because most of the hard processing work is for multipolygons
relations anyway.

Regards

Sven

-- 
If you continue running Windows, your system may become unstable.
(Windows 95 BSOD)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Using custom renderer with mod_tile

[Sven Geggus]

Skye Book skye.b...@gmail.com wrote:

 Thanks for the clear explanation.. That meshes well with what I understood
 from reading the wiki and cursory looks at source code

http://wiki.openstreetmap.org/wiki/Tirex/Overview has a nice diagram about
how the different modules communicate.

It is possible to run different backends in parallel.

Sven

-- 
How to prevent Java from forking? Use a spoon.
(Found on http://slashdot.org)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql patch for nested relations

[Sven Geggus]

sly (sylvain letuffe) li...@letuffe.org wrote:

 Reading that thread, I remembered that I don't need type=route either, I've 
 commented that part of osm2pgsql but the speed gain is hardly noticeable (if 
 at all)

Quite in contrast to multipolygon relations, there is almost no computation
in route relations, their member ways are just added to the planet_osm_lines
table, they are not even concatenated.

Sven

-- 
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] osm2pgsql patch for nested relations

[Sven Geggus]

Frederik Ramm frede...@remote.org wrote:

 If we start coding special cases into osm2pgsql, we have to code the same
 special cases into lots of other applications too.

AFAIK osm2pgsql currently supports two types of relations:
type=route amd type=multipolygon.

Both of them _are_ special cases.

You are right that relation support should be implemented in a more generic
way, but currently this is simply not the case anyway.

Sven

-- 
Der normale Bürger ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Osm2pgsql not importing routes?

[Sven Geggus]

yvecai yve...@gmail.com wrote:

 Which contains 49 relations according to osm2pgsql output, but the 
 following requests find nothing:
 
select count(*) from planet_osm_line where osm_id = -1401913;
select count(*) from planet_osm_line where osm_id  0;
 
 and the column route_name does not exists.

You might consider importing using a hstore column for test purposes.

name will be changed to route_name during import and _only_ routes with
a type=route tag (well, not the routes themselves, just their members) get
imported at all.

I just tested on a full planet Database featuring hstore and using the most
recent Version of osm2pgsql.

Looks fine IMO:
osm= select count(*) from planet_osm_line where osm_id = -1401913;
 count 
---
 1
(1 Zeile)

osm= select tags from planet_osm_line where osm_id = -1401913;
 tags   
   
---
 color=green, piste:type=nordic, route_name=Haute Joux, 
route_pref_color=0
(1 Zeile)

Regards

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] processed_p.tar.bz2 inverted?

[Sven Geggus]

Paul Norman penor...@mac.com wrote:

 You might be able to generate an inverted one by inverting the
 coastline_*.shp files before passing them to the rest of the coastcheck
 process to generate processed_p.

Is this coastcheck process a documented workflow?

Sven

-- 
Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen
(Wolfgang Schäuble)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] processed_p.tar.bz2 inverted?

[Sven Geggus]

Paul Norman penor...@mac.com wrote:

 You might be able to generate an inverted one by inverting the
 coastline_*.shp files before passing them to the rest of the coastcheck
 process to generate processed_p.

Are these available for download somewhere or would I need to extract them
from a planetfile?

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] processed_p.tar.bz2 inverted?

[Sven Geggus]

Hello,

this is probably more of a GIS Question than an OSM one.

For a nice combination of hillshade and water I would like to invert
the processed_p.shp file from http://tile.openstreetmap.org/processed_p.tar.bz2

This should prevent rendering of hillshaded water on the edges as
water can be rendered above hillshades this way.

Unfortunately this does not seem to be as easy as it sounds.

I tried to import it into postgis and using ST_Difference but it
looks like processed_p.shp is somewhat broken.

Any other hint ob how this could be done?

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] Our #switch2osm story

[Sven Geggus]

Helge Fahrnberger he...@toursprung.com wrote:

 As existing options don't cater very well for the world of tourism
 and outdoor sports we have decided to render our own tiles, with
 hill shading and contours.

Would you mind sharing some Information about the technology in use?

tirex, mod_tile, tilecache, mapnik, mapserver, TileMill, ...

Sven

-- 
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] Rendering rivers in real width

[Sven Geggus]

Hello,

on Osmarender I once implemented rendering of rivers, stream, canal,
etc.  in their real width.  A Cartographer once told me that unlike
roads waterbodies are usually drawn in their real extent on maps
after all.

With Osmarender beeing abandoned now, there will soon be no map
available anymore which includes such a feature.

Thus I just commited a small patch for osm2pgsql which will produce
suitable width columns with real values for this.

I have already been able to render a small test Map using Mapserver
and this simple Style:

LAYER
MAXSCALEDENOM  50
STATUS ON 
GROUP default 
CONNECTIONTYPE postgis 
CONNECTION dbname=gis
PROCESSING CLOSE_CONNECTION=DEFER 
TYPE LINE
NAME rivers
# 10m is the default width
DATA way from (select way,osm_id,coalesce(width, 10) as width from 
planet_osm_line
where waterway in 
('river','canal','derelict_canal','stream','drain','ditch','wadi'))
as foo using unique osm_id using srid=900913
SIZEUNITS meters

CLASS   
STYLE
 MAXWIDTH 200
 WIDTH [width]
 COLOR #ff
END
END
END

It has been said that something like this is not possible to do in Mapnik (at 
least in
version 1).

So, talking about Mapnik2, ist there a way fo a data-driven control
of stroke-width in LineSymbolizer.

Sven

-- 
Unix is simple and coherent, but it takes a genius – or at any rate a
programmer – to understand and appreciate the simplicity
(Dennis M. Ritchie)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-dev] ANNOUNCEMENT: T@H server will go away end of February

[Sven Geggus]

Matthias Meißer dig...@arcor.de wrote:

 Bad to hear. But maybe this is the right moment, we should care about a 
 real easy to use distributed rendering approach, again?

To be serious, I consider distributed rendering broken by design.

Here is why: 

Distributed computing is usually a good idea when computing takes more time
than data transmission. Otherwise it just does not make sense to transmit
the data rather then just computing it right at the place where it is
needed.

What is probably needed for OSM in the long run is some kind of
geographically distributed rendering e.g. rendering divided by continent.

Sven

-- 
A strategy for rewarding artists that regulates 'copies' makes as much sense
in the digital age as a strategy for controlling greenhouse gases that
regulates breathing. (Lawrence Lessig)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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