Helge Fahrnberger 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,
Matthias Meißer 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 comput
Jukka Rahkonen wrote:
> If you select that road I would love to see it able to write into
> Spatialite as well.
osm2pgsql has not been designed (if designed at all) with various backends
in mind but contains pretty much hardcoded assumptions about the Database in
use. I'm afraid redesigning it i
Kai Krueger wrote:
> We should try and get more of the rendering tool stack into the standard
> repositories of Ubuntu and Feodora.
If you convince just one Debian Maintainer to package them they will end up
beeing added to Ubuntu sooner or later anyway.
Sven
--
"Ich fürchte mich nicht vor d
Hello,
I'm trying to render a hillshade+contour baselayer. This is loosely based on the
manual in the Wiki http://wiki.openstreetmap.org/wiki/HikingBikingMaps.
Looks like my stylefile is somewhat broken because calling nik2img.py I get
this:
...
Step: 14 // --> Extent of all layers:
Envelope(-3
BG wrote:
> But the geometry column (which comes with postgis) confuses me, this is
> a bunch of numbers.
It's a OGC standard Format called Well Known Binary (WKB)
Postgis provides a funktion (astext) which will transform it to WKT
(Well known text).
http://www.opengeospatial.org/standards
R
Jukka Rahkonen wrote:
> No own development done, just playing with existing possibilities of
> MapServer WMS and WFS and osm2pgsql with hstore.
Would you mind sharing your Mapfile?
Sven
--
How to prevent Java from forking? Use a spoon.
(Found on http://slashdot.org)
/me is giggls@ircnet, htt
Frederik Ramm wrote:
> To be a bit clearer on the procedure to fix things: Either re-import, or
> re-create indexes
Hm, am I right in the assumption that this problem will affect any index
of type gin not just the two created by osm2pgsql?
I wonder if my hstore tags-column indexes should also
Frederik Ramm wrote:
>this is about a bug in osm2pgsql that will affect you if you
>
> * run diff updates (--slim --append)
> * run PostgreSQL 8.4 or 9.0
> * use an osm2pgsql SVN revision >= 25198 (2011-01-31) and < 26475 (today)
> * are not using non-standard index tablespaces (-i or --tabl
Stefan Keller wrote:
> So to save disk space and resources my feature request is being able
> to control which extra-attributes go into hstore - or at least simply
> ignoring "osm_user" while parsing input stream.
I did not ever try --extra-attributes in conjunction with --hstore thus I do
not k
M∡rtin Koppenhoefer wrote:
> I installed tirex with make (not with the package manager)
If you are running Debian or Ubuntu you are better of doing the latter.
This is just a matter of
svn co http://svn.openstreetmap.org/applications/utils/tirex/
and running dpkg-buildpackage
Sven
--
Der "no
Stefan Keller wrote:
> In our case we use osm2pgsql in Version 0.70.5
As the Version number is usually not increased on every commit a svn commit
number would be the Version Number needed.
Sven
--
"The term "any key" does not refer to a particular key on the keyboard. It
simply means to strik
Jukka Rahkonen wrote:
> Am I right in thinking that if there were suitable diffs available it
> would be much faster to update directly the osm_point, osm_line and
> osm_polygon tables without going through osm_points, osm_ways and
> osm_rels?
This would not work because these tables are differe
Sven Geggus wrote:
> Hm looks like I broke something :(
Puh, fortunately it looks like I did not :)
planet_osm_polygon and planet_osm_line are fine in either case here:
--hstore, --hstore-all and no hstore.
Just 4TR:
I'm running a custom backport of postresql 9.0 and postgis.
O
Stefan Keller wrote:
> Unfortunately, only the osm_point table was filled with data,
> osm_polygon and osm_line were empty. This was not the case before the
> upgrade of the mentioned components.
Hm looks like I broke something :(
I did not try --hstore-all anymore after adding the new hstore
b
Ian Dees wrote:
> On subsequent updates osm2psgql does not have node information in memory
> anymore, so it must request the node information from PostgreSQL. This takes
> orders of magnitudes longer to do than a hit to memory.
I just read about new features in PostgreSQL 9.1:
http://lwn.net/Sub
Sven Geggus wrote:
> The initial import is very fast (with pbf) and still fast (with .osm.bz2).
> It is just updates which are very slow here.
Hm, I just verified this. The import is fast enough (about 10 hours) but I
did expect it to be even faster.
What are the expected values here?
Markus Wagner wrote:
> Is the data organization on the LVM comparable to a RAID-0 ?
The Linux RAID driver does not support SATA TRIM, thats why I'm using lvm
here.
My setup is loosely based on this HOWTO:
http://www.ocztechnologyforum.com/forum/archive/index.php/t-82648.html
So yes, this is mo
Markus Wagner wrote:
> After vacuuming and fiddling with those values I am much closer to
> realtime. Currently at approx ~120% of realtime. So I think, there is
> hope, once I get faster disks.
I'm reopening this thread because I have a very simular Problem and I
suspect that this could be an i
Sven Geggus wrote:
> *argh* this is not intentional. I did not think about write_wkts beeing
> called a second time. Looks like I need to do this in another way.
OK, fixed in r25786. Bad Idea to remove the k/v pairs from the list. I
changed this to just flag them as having their own colu
Lennard wrote:
> What probably happens is that, in write_wkts(), you removeTag(), thereby
> physically removing that tag from the list. However, for geometries that
> also go into planet_osm_roads, write_wkts() is called twice in a row
> (once for lines, once for roads), and the second time, t
4YI,
i just commited a small change to the hstore functionality in osm2pqgsl.
Until now any tag has been added to the hstore column regardless if this key
had an exclusive column or not. This has been changed now.
For people who really need all tags in the hstore column an additional
commandline
Christian H. Bruhn wrote:
> Could someone please update the Windows binary of osm2psql [1]. The
> file is almost 1 year old and doesn't support pbf.
Well, PBF support has been added, but this is one of the reasons why it is
not that easy anymore to build a full featured osm2psql, even on Linux.
Oliver Tonnhofer wrote:
> PostGIS for now, but it could be extended to support SQLite, etc. It is
> similar to osm2pgsql but it supports more customizable database schemas.
Do you have support for incremental database updates?
Sven
--
Der "normale Bürger" ist nicht an der TU Dresden und schre
Frederik Ramm wrote:
> There may be breakage on Debian as well but I've only witnessed on
> Ubuntu.
Version 25081 does compile just fine in Debian lenny (hopefully oldstable
after next weekend) and squeeze (hopefully stable after next weekend). So
this looks like a Ubuntu only bug.
Sven
--
Mi
Frederik Ramm wrote:
> Has anyone done some experimentation in that direction? I know that
> Nop's riding+walking map uses three layers (OSM background, third-party
> hillshading, OSM foreground), and of course I've seen the grand
> ImageMagick-based TopOSM. Has anyone tried a multi-overlay ti
Peter Körner wrote:
> Sorry, you're right. I'd love to see a version of this how to with
> mapnik 0.8.0 on a debian unstable or testing system.
0.8 has not yet been releasead AFAIK and would require major changes
in our styles anyway.
Debian testing has 0.7.1
Sven
--
"The only thing we hav
Andreas Kalsch wrote:
> Example for unnessessary complex schema design:
> http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore
You are welcome to design a better database scheme suitable for rendering :)
osm2pgsql output is evolution _not_ design.
Using a join in every single SQL reque
Andreas Kalsch wrote:
> I think it is not a good idea to use hstore because then we can drop SQL,
> use NoSQL for storing data and use PostGIS/Postgres for Geometry only.
In the real world there is no black and white! Shure, hstore is comparable
to NoSQL aproaches, but why should it be a bad thi
M∡rtin Koppenhoefer wrote:
> yes, I did this because I don't know how to get a "proper package" for
> mapnik, thank you.
This should be as simple as apt-get install libmapnik-dev
Sven
--
Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp
Chris Browet wrote:
>> > Actually, I could develop a pbf 2 whatever, via GDAL.
>>
>> Native osm or pbf support for gdal/ogr would be really nice.
>>
>> Er, sure, but it is not quite the point, here...
You have been talking about pbf2foo which would be basically the same as
osm/pbf input format s
Chris Browet wrote:
> Actually, I could develop a pbf 2 whatever, via GDAL.
Native osm or pbf support for gdal/ogr would be really nice.
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 g
M∡rtin Koppenhoefer wrote:
> please don't drop the osm.bz2 (xml) version in the near future, there
> is a lot of people relying on it, and geofabrik already announced that
> they might drop their version of osm.bz2 (pointing out that there
> would still be the planet).
pbf2osm is available in os
Peter Körner wrote:
>> The reason for this check is that it does not seem to work with Version 0.12
>> which is the default protobuc-c Version in Debian testing.
>
> Is it really protobu>c< or is it protobu>fhttp://sven.gegg.us/ on the Web
___
dev mai
Jon Burgess wrote:
> Does "protobuc-c" exist or is this a typo?
The package is called libprotobuf-c0-dev (in Debian/unstable).
> protobuc-c >= 0.14: no
The reason for this check is that it does not seem to work with Version 0.12
which is the default protobuc-c Version in Debian testing.
Sven
Hartmut Holzgraefe wrote:
> i have commit access, the changes are quite massive by now though,
> so i'd like to get at least some feedback before pushing the changes
> to SVN ...
Hm, when using ordinary osm file and no -r switch I get the
following:
Input parser `libxml2' not recognised. Should
Hartmut Holzgraefe wrote:
> took a bit to figure out that things do not work the protobuf-c version
> that comes with Ubuntu Maverik.
Which Version is this?
Hot some trouble on debian squeeze as well:
src/ > ./pbf2osm ~/saarland.osm.pbf
error parsing member id of DenseNodes
error parsing
Peter Körner schrieb am Montag, den 13. September um 17:41 Uhr:
> This approach seems to be the best one. It should be a fairly simple
> modification to osm2pgsql.
OK, I had a quick look. Unfortunately this part is implemented in the C++
part of osm2pgsql because of the geos library.
I'm glad to
Peter Körner schrieb am Montag, den 13. September um 16:53 Uhr:
> Yes, that's a known problem (or feature?). OSM allows invalid
> geometries for polygons and mapnik can render them, but some
> postgis functions will fail. It is possible to use ST_IsValid but
> this adds a medium runtime penalty.
Jukka Rahkonen wrote:
> My source data is Finland.osm file imported into PostGIS with -k option
> for getting all the tags. Sea and borders layers are from Vmap0. Images
> are rendered on-demand, and data can be selected by editing the &tag= and
> &value parameters.
Nice! The only thing which sh
Andy Allan wrote:
> Does anyone have a list of services (or maps etc) which don't cover
> North America?
All in One Garmin Map comes to mind. This map is very handy because there
are Openstreetbugs and Fixme layers.
Unfortunately we can not provide the processing power to produce a worldwide
Ve
Yuliya Leonova wrote:
> For now in Mapzen for tagging building name parameter we use
> 'addr:housename' tag.
> But recently Mapzen team have got several requests to change it to just
> 'name' tag key.
addr:housename ist meant for postal purposes only (Part of an address in
house-numbering scheme
Michael Kussmaul wrote:
> It seems including malloc.h is anyway unnecessary, as stdlib.h already
> takes care to get the correct malloc implementation - so after removing
> the line
>
> #include
>
> in the file middle-pgsql.c, everything went fine.
Right! According to the Linux manapage stdli
Ævar Arnfjörð Bjarmason wrote:
> Frederik probably has a better way, but one way of doing it to just
> add unstable as a apt archive and install libmapnik-dev from there
> instead of stable.
This is almost certainly a bad Idea. The generic way is doing a
backport using apt-get source.
Sven
--
Jukka Rahkonen wrote:
> Right, username can be given after -U parameter and -W can be used to make
> osm2pgsql to ask for the password. It is not possible to give the
> password from command line as -W my_password, it makes osm2pgsql to behave
> oddly. If I remember right it is trying to open an
Jukka Rahkonen wrote:
> Sven Geggus has made a pretty good job with adding this fine
> feature into osm2pgsql.
Thanks. Credits should also go to Jochen Topf for suggesting hstore
as a well suited storage Method for OSM Data in the first place :)
Peter and the the other Wikipedia Peop
Simon Gornall wrote:
> At least on my system (10.6.3) I had to add:
>
>CPPFLAGS = $(CFLAGS)
>
> ... to get the Makefile to build build_geometry.cpp
> - otherwise there were no CFLAGS set, and the build failed.
Are you using a recent Version whith autoconf support? Autoconf support has
Lennard wrote:
> There's another few functions that aren't being called anymore, either.
Can you name them? output-pgsql.c is already about 1500 lines of code so
removing unused function will do no harm as they stay available via svn
history anyway.
Sven
--
"If you don't make lower-resolution
Hello,
fiddling with the code of osm2pgsql I came across the
add_parking_node function which does not seem to be called anywhere
as far as I can tell.
Can anybody confirm this?
Sven
--
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars an
strk wrote:
> Find it attached :)
I think you should get youself a subversion account and commit it
yourself.
We could do this for you, but I think it would be better if patches are
commited by the Authors themselves just to know who to blame :)
Sven
--
How to prevent Java from forking? Use
Sven Geggus wrote:
> Currently the patch has not been tested in conjunction with
> incemental database updates.
OK, in the meantime I can confirm, that incemental database updates
work fine. I just fixed a problem with polygons (SVN r20565). When
using hstores we need a way to mark polygo
Jochen Topf wrote:
> I contacted the guy running wms.openstreetmap.de
/me
> to see whether we have some space on that server. I think we are running
> out of disk space, but we'll see.
There are still about 700 Gigabytes available so we will probably be able to
host at least some of the data.
Lennard wrote:
> Very cool this. What's the speed to access the hstore column, compared
> to the generic columns we now have?
I did not yet try to measure this.
> On the one hand, this has the potential to greatly increase the size of
> the db, as you will now get all kinds of tags you're nev
Martijn van Oosterhout schrieb am Sonntag, den 14. März um 17:06 Uhr:
> Very cool. Now we just need to find a way to use it. I thought about
> it earlier but I didn't see a way to make mapnik use it so left it.
This won't work?!
I didn't bother with this yet, but I just thougt that all I would
n
Hello,
I just commited a patch for osm2pgsl for optional generation of a
hstore column (hstore new).
For those of you who don't know about hstore colums yet:
Hstore is for sets of key/value pairs. As associative array datatype,
just like a hash in perl or dictionary in python.
This should come
Hi there,
I think about setting up a WFS Server with Openstreetmap Data.
Using osm2pgsql and mapserver this is more or less a trivial thing to
do.
Currently I tested this using osm2pgsql.
What I would need for this matter is however some kind of incremental
Postgis Database update, as automated
Hello,
I'm fiddling with mapnik, but am currently not able to generate
geographically correct tiles.
My generated tiles always seem to be shifted north by
approximately the height of one tile (I did not measure this exactly
however).
I'm using generate_tiles.py from svn more or less unmodified.
Hello anybody,
can someone explain to me why the osm_id column generated from osm2pgsql
is just almost but not completely unique?
The reason I ask, is that tools like qgis need an unique column to work,
which I thought osm_id would be.
There are very few of them (e.g. 9 lines out of 173733 in my
101 - 158 of 158 matches
Mail list logo
