Hi,
On Wed, 9 Mar 2011 19:01:37 -0500
Gregory Casamento greg.casame...@gmail.com wrote:
I am currently working on a solution for one of my own projects (not
GNUstep related) which involves routing. I'm wondering if there are
any Mac (NOT IPHONE OR IOS) based solutions which can do what I'm
Hi,
On 03/10/2011 02:07 PM, Andrew wrote:
People who write editing tools can also exert a lot of leverage, for instance
by having their programs used by mappers who are less skilled and experienced
than they are themselves. What do you see as being the standards the community
expects of editor
Hi,
On 03/10/2011 03:46 PM, Gregory Casamento wrote:
Well, by routing I mean the ability to show a navigable route on the
nap from one point to another.
I am still unsure if you are looking for code that does the map display
and all, or just a routing engine that spits out a number of
with such large images in Mapserver but
just to be sure - you do know about the overview pyramids one uses with
such images
(http://mapserver.org/input/raster.html#rasters-and-tile-indexing,
http://www.gdal.org/gdaladdo.html)?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09
Hi,
On 03/15/11 09:51, Nick Whitelegg wrote:
If I don't use slim mode I get out of memory errors when importing the
tracks file (the others are small enough so go in OK) - have to admit
I'm surprised I get out of memory errors as it's only a 176MB file.
osm2pgqsl allocates memory in blocks of
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 03/30/2011 01:21 PM, Jason Lee wrote:
Regarding multiple instances, I am just thinking in terms of performance
and stability. If I had 2 instances of renderd and one error's for
whatever reason, then at least it is not affecting the other service.
Having two renderd processes serving
Hi,
Some specs of my setup:
-Debian 64Bit
-PostgreSQL 9.0.3, PostGIS 1.5.2; having its own physical drive with
XFS -Intel(R) Core(TM)2 Quad CPU Q9505 @ 2.83GHz
Make sure you've got at least osm2pgsql r25198 (31st Jan) as this will
turn the fastupdate feature off. The impact of this is most
Scott,
On Wed, 6 Apr 2011 22:06:57 -0500
I believe the osmosis database representation for a planet is not the
same as what is used by osm servers. OSM servers use a special dump
program for generating planets.
I think Eric was talking about the history planets,
not the normal planet files.
Hi,
On 04/12/2011 02:58 AM, Ian Dees wrote:
The most recent dev version of MongoDB includes multi-location
documents support:
http://www.mongodb.org/display/DOCS/Geospatial+Indexing#GeospatialIndexing-MultilocationDocuments
This would allow a single way document to be indexed at multiple
have in regard to implied tags is, whether an
implied tag can in turn imply other tags.
You are assuming that implied tags are a widely known and used concept
and that there are certain logical rules for that. There aren't, to my
knowledge.
Bye
Frederik
--
Frederik Ramm ## eMail frede
application).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
that
the user knows why they got the message and that they need to log in to
openstreetmap.org etc.etc.)?
Should we make an effort to catch the error in order to allow a translation?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
On 04/14/2011 08:52 AM, Frederik Ramm wrote:
find all nodes in that area, then find all objects using these nodes,
then check if any of them has a pharmacy tag, or the other way round,
first find all objects world-wide that have a pharmacy tag, then find
s/pharmacy/traffic light/
Bye
Hi,
On 04/14/2011 10:12 AM, the.promena...@gmail.com wrote:
I made another suggestion here -
http://www.openstreetmap.org/user/ThePromenader/diary/13574 - that'll
be all for this week ; ). Thanks for any input.
I think you're mixing up the data model, the editing, the rendering, and
the
Hi,
On 04/15/2011 04:16 AM, Ben Supnik wrote:
- Is there any chance of having an area primitive so scalable that it
scales all the way up to the major continents? Right now continents are
sort of an exception - you need to go pull down the pre-processed
coastline shape files because the data
database for rendering and Nominatim.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
is required for rendering and what is required for nominatim. Maybe it
can be done; it would certainly be something that many people would like
to use.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev
Hi,
On 04/19/11 09:39, the.promena...@gmail.com wrote:
I made yet another suggestion here -
http://www.openstreetmap.org/user/ThePromenader/diary/13610 . Thanks for any
input.
Your suggestion does not suggest anything that has not already been
written in
Ben,
On 04/19/11 13:29, Ben Supnik wrote:
You explain building=yes as meaning is it filled?, when in reality
it is completely up to the renderer whether or not to fill an object
that is tagged to be a building.
Wait, I don't think I agree with this. That is, to me, the question of
whether a
Hi,
On 04/19/11 13:59, Ben Supnik wrote:
Right...I think the original poster and myself are advocating that a
spatial notion of area be in the data model, but we are definitely NOT
arguing to take visualization decision making away from a renderer.
My main issue with the original poster was
Hi,
On 04/20/11 17:51, Ben Supnik wrote:
3. We sanity check the incoming data. This is fairly specific to our app
case and may not be appropriate for others. If a way goes straight up a
mountain at a 80 degree slope and its type is motorway=trunk, we throw
it out. It's much more likely that
Hi,
with the license change likely to occupy us for the next year or so,
the question who has edited this object, and have they all agreed to
the new license? will become more important for some use cases (most
notably editors). If you're only interested in one or two objects then
you can
Dermot,
On 04/24/2011 02:19 AM, Dermot McNally wrote:
I see that user names are not provided. Is that for reasons of
discretion, volatility or performance?
Two reasons: 1. There's really no elegant mechanism to handle user name
changes. An object may have been edited by you while your user
not understand the new format can continue to work?
...
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
Pierre-Alain Dorange wrote:
./osmosis --rb france.osm.pbf -tf accept-nodes place=* --wx
fr_places.osm
You're missing the second - before tf, making Osmosis think that
-tf was a second argument to --rb.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008
of the chain
but I remember some past discussion on the Osmosis list about potential
deadlocks if you combine what you have split in the same task.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing
line must be
removed, and then without explicitly specifying the in/out pipes, the
second and third block of --tf rules would be applied in sequence
rather than in parallel!
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
On Wed, 27 Apr 2011 01:29:08 -0700 (PDT)
NopMap ekkeh...@gmx.de wrote:
Paging the admins of the OSM tile servers. I'd like to get in touch
about the topic of mass downloaders. It appears that some problems
first become visible on small tile servers like my own, but hit the
main tile
know that
works. It seems to work more by accident than by design though.
Do I really need to unpack the full history planet to use this or can I
use bzcat?
You can pipe something in.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
, and that the attribution is so-and-so?
Probably not, which means that as long as you don't explicitly support
OSM you don't need attribution, right?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev
Hi,
On 05/06/11 09:17, NopMap wrote:
If you design your dedicated map handling system in such a way that it is
impossible to add and display proper attribution when adding a new map
source manually, even if you wanted to, that application is clearly
violating any attribution licence.
translates to
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Areas_on_Nodes
and would have the disadvantages listed on that page (e.g. no re-using
of edges; difficulties in handling very large polygons).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Uffek,
On 05/09/11 11:33, uffeK wrote:
We have compiled the osm2shp converter by Frederik Ramm and have tried to
extend it with additional fields, in order to include ferries.
We call it this way, with the last 2 lines having been added:
shapefile_new(2, SHPT_ARC, roads, 9
Hi,
On 05/09/11 11:36, Jukka Rahkonen wrote:
Polygons are formed from the linestrings through a middle table. Polygon
table contains polygon-IDs and the attributes which belong for the polygon
features. The middle table is taking care of handling the many-to-many
relationships by connecting
Hi,
On 05/09/11 12:21, Jukka Rahkonen wrote:
And if one does not like GML, one can select for example GeoJson instead
Oh ;)
and with Mapserver v. 6.0 all vector formats supported by ogr for writing
are supported also as WFS outputformats. They are marked as Creation=Yes
on the list
Hi,
On 05/09/11 12:33, uffeK wrote:
But there must be a standard?
No. OSM doesn't do standards ;) It is good that you have checked the
values in use; now simply make your application so that it understands both.
Bye
Frederik
___
dev mailing list
diff that only pictures the difference between two
snapshots.
Opinions? Ideas?
While you're at it, why not define a set of MIME types to go along.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing
Hi,
On 05/11/11 13:23, Peter Körner wrote:
that way it is useful for a program to know, if a file fed into it via
stdin will be processed fine right from the start. nobody likes
processes that fail after 10 hours because of a missing
--this-is-an-history-file flag.
Yeah, fast failing is
Hi,
On 05/11/11 15:31, Brett Henderson wrote:
I then used the osc file format to create not only the commonly used
daily/hourly/minutely replication files, but also a complete dump of
database history updated daily (stored in one file per day).
http://planet.openstreetmap.org/history/
I was
Hi,
I'm sure I have announced this somewhere a while ago but cannot find
it now, so pardon me if you're reading this for the second time.
A student from Karlsruhe, Jakob Altenstein, has done his Bachelor thesis
on the OSM license change, looking at ways to compute the effect of the
Hi,
not long now and we'll have our nodes IDs exceed the magical 2^31-1
limit, a time at which many applications will doubtless experience their
own little version of the year 2000 problem ;)
I have modified osm2pgsql to support 64 bit IDs (int8/bigint on
PostgreSQL). The modified
Hi,
On 05/21/2011 03:53 AM, Igor Brejc wrote:
Can you give some rough estimates on how much time we still have until
this 64bit issue comes up?
My rough estimate would be that it *may* happen around the end of this
year, but more likely around mid-2012. Of course this depends heavily on
how
are defined for 32/64 bit mode.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 05/24/11 11:24, Igor Brejc wrote:
This could be a more serious issue. I guess in the history of GIS there
has never been such a large geo database as OSM is now becoming. Maybe
we (as the OSM community) should take a proactive stance and propose a
new version of shapefile format that
Hi,
On 05/24/11 12:04, Igor Brejc wrote:
Yes, but is it really? It's a storage format, you need a 3rd party
driver to read it
Same for anything that uses protocol buffers, or for shapefiles, isn't it?
and it's optimized for querying, not for storing high
volume of data in an efficient
Hi,
On 05/24/11 13:31, Manuel Reimer wrote:
I have a problem with the following view:
http://www.openstreetmap.org/?mlat=49.993605mlon=9.684956zoom=18
OSM Inspector
http://tools.geofabrik.de/osmi/?view=geometrylat=49.993605lon=9.684956zoom=18
claims a role mismatch - you have tagged that
Hi,
On 05/24/11 17:05, Igor Brejc wrote:
Not necessarily the same thing. Writing protobuf reader is still much
easier than implementing something like
http://www.sqlite.org/fileformat.html and
http://www.sqlite.org/fileformat2.html
If you say so - I thought that dealing with protobuf files
command line?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 05/30/11 16:43, Peter Körner wrote:
But since I already use osm2pgsql and since I'd like to maintain only
one database, it would be nice to attach Java XAPI to it.
The databases are not compatible, it's not possible to run both tools on
a single database.
Well... in slim mode,
Hi,
On 05/30/11 17:04, Peter Körner wrote:
Well... in slim mode, osm2pgsql already tracks all nodes and the
relationships between nodes, ways, and relations;
[...]
osm2pgsql throws away all objects that don't have the right tags if you
don't use the hstore features and it don't store
Hi,
On 05/30/11 17:19, Peter Körner wrote:
If your options are (a) run both a pgsnapshot and slim-mode osm2pgsql
database on the same machine and keep them both up to date
independently, or (b) trick osm2pgsql into generating something that
is compatible enough with pgsnapshot so that you can
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 05/31/11 23:43, Sergey Galuzo wrote:
Obvious differences between full and change are explicit
create/modify/delete tags.
We have full history OSM files and normal OSM files (both use .osm
extension and osm.../osm), and we have simple diffs and replication
diffs (both use .osc and
Hi,
On 06/01/11 18:22, Benjamin Meier wrote:
I'm looking for the fastest way to extract a bounding box from osm-data.
The intention is to get a section (a square of about 5km * 5km)
around a user's current position in a few seconds.
Are you sure you want raw OSM data - or maybe rather
too
much clutter. (If I were in charge I'd say the latter but I don't want
to pre-empt anyone.)
Btw. there's a surface view on ITO:
http://www.itoworld.com/product/data/ito_map/main?view=25
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
) but
is less suitable as a master data type.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
, else you
wouldn't know if there's a connection.
Do you care to elaborate on what the disadvantages would be?
No, I'm not prepared to discuss them with you.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
).
Easiest way: Open JOSM, load OSM tiles in backgruond, do not load OSM
data, draw one closed way around the county, save as .osm, run through
osm2poly.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev
look very
nice most of the time.
Is the style you made for Sydney open source? What changes did you make
to support z20?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
tirex will *always* keep maxproc CPUs of the lowest
priority queue busy. This means that I don't usually set that to
anything more than 4 even on a 16-core machine.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
On 06/15/2011 09:48 AM, Oliver Tonnhofer wrote:
- display less data in low scales
- add indices for columns you filter on
There are scripts in
svn.openstreetmap.org/applications/rendering/mapnik/utils/
that can help you find out which of your rendering rules take the most
time to
Hi,
On 06/15/11 18:18, NopMap wrote:
On a side note: I have always had the problem that tirex on my server
crashes on occasion (about once a month) while adding a few 1000 new tiles
for rendering to a non-empty queue.
I had that earlier; for some reason tirex-batch and the master process
-import-complete in the root tile
directory, and that the time stamp of this file is earlier than your
earliest metatile.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
Hi,
On 06/20/11 16:14, Parveen Arora wrote:
But If I have to generate tiles for a small area or let us say for a
city that does not include world boundaries, In that case do we need
them?
If you're not rendering any oceans, simply change the map background
colour from blue to gray and do
Hi,
On 06/20/11 16:53, Parveen Arora wrote:
If you're not rendering any oceans, simply change the map background colour
from blue to gray and do away with the shape files.
Is it only for the oceans or also for the world boundaries that
doesn't include in any ocean.
I think the shapes also
Hi,
as you know I've recently made the osm2pgsql-64 branch which does
not use intarray. The osm2pgsql-64 branch is capable of handling 64-bit
IDs but can also be defined to use 32-bit IDs like the classic osm2pgsql.
I would encourage everyone to move to the osm2pgsql-64 branch as soon as
Hi,
On 06/22/11 18:51, Stephan Knauss wrote:
this afternoon my update process got stuck. Running on linux. according
to ps it's in state Sl.
It's stated with these arguments:
osmosis -q --rri --bc --simc --bc --write-xml-change - |
I guess killing it is all it takes to recover. But is there any
Hi,
On 06/23/2011 01:19 PM, Parveen Arora wrote:
As we can import the OSM data file into the database using osm2pgsql,
I want to know that can we optimise that data before importing.
Means If I need only the Information of National Highways, what is the
need of storing all the data in the
Hi,
On 06/24/11 17:35, Manuel Reimer wrote:
is there a bugtracker available for osm2pgsql?
Yes, you can use the normal trac system for that. Login is the same as
your OSM login.
I think I'll create a patch, which modifies the build system to work the
way it should (doesn't make any sense
Hi,
On 06/27/11 10:04, Günter Dressel wrote:
we are running nominatim (rev. 25615) since a couple month now.
Our PostGIS Database reached the 2 Terabyte mark at beginning of may 2011.
Still level 30 gets processed, and in the last weeks we couldn't monitor any
valuable changes at the database.
=2 file.osm.bz2
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
Anthony wrote:
That's with the bz2 format. Try it with the 7z format.
Oops, sorry, I had assumed it would work the same.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev
Hi,
On 07/18/11 12:38, Andrew Ayre wrote:
Hi, I know there is a command line limit in Linux, but what is the limit
on the number of tees in Osmosis? I am thinking of taking a single osm
file and applying a large number of bounding boxes to it in one go,
rather than continually subdividing and
Hi,
On 07/21/2011 10:07 AM, Andrew Ayre wrote:
What protection is there in Osmosis to recover from this without missing
any changes? If none, how are people solving this in their scripts?
I usually do this:
* get latest changes, save in latest.osc
* if a file named changes-to-apply.osc
Hi,
On 07/21/11 10:07, Andrew Ayre wrote:
What protection is there in Osmosis to recover from this without missing
any changes? If none, how are people solving this in their scripts?
One other thing comes to mind. The most frequent problem with my
minutely Osmosis updates is that about once
come
first, then all way members, then all relation members, and way_off is
the index of the first way member and rel_off the index of the first
relation member.
The pending flag is a dirty marker used during diff updates.
= Any hints?
Read the source, Luke ;)
Bye
Frederik
--
Frederik
Hi,
Frederik Ramm wrote:
[...]
Or, what Jon said ;)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 07/27/11 16:08, sly (sylvain letuffe) wrote:
Well no, because I don't use mod_tile, but that is a good idea, instead of
blocking completly the ability to download, reducing/limiting the hit rate
per minute per IP might be a good idea. I'll try to do something about that.
On my server I
Hi,
On 07/27/11 16:52, Josh Doe wrote:
I'm curious if anyone has ever attempted to convert the massive OSM
Mapnik stylesheet to one of the CSS-like languages such as Cascadenik or
Carto.
Paul Hartmann has done a Mapnik to MapCSS converter
OSM circles (or maybe Carto has the superior design or super
cool features that MapCSS hasn't); I wouldn't know. Hence my question if
there's a good comparison anywhere, ideally by someone who wasn't
involved in the development of either.
Bye
Frederik
--
Frederik Ramm ## eMail frede
Hi,
On 07/28/11 09:53, Andy Allan wrote:
No comparison that I'm aware of, but carto certainly has advantages. I
would say that MapCSS is very primitive when you consider the range of
symbolizers and attributes that mapnik (and hence cascadenik/carto)
support compared to any of the engines that
anyway.
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
for rendering).
Don't attempt to apply a diff update without these indexes in place.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org
Hi,
On 08/08/11 19:08, mar...@gmx.eu wrote:
The target database has the intarray contrib module loaded.
While required for earlier versions of osm2pgsql, intarray
is now unnecessary and will interfere with osm2pgsql's array
handling. Please use a database without intarray.
Simply drop your
wouldn't use the index
properly in these cases.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
Stephan Knauss wrote:
On 07.08.2011 21:19, Frederik Ramm wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes with
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING
the index.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi,
On 08/11/2011 07:07 PM, ant wrote:
The reason why it bothers me is that I feel my program should deal with
these cases. So the technical part of my question is: How does the API
handle it? Which of the above should I expect to be found in the planet
file, which not?
To the API, a way is
of them.
This optimisation/problem does not exist in the 64-bit branch that got
promoted to the current version recently.
An oversight on my part, I should have added that to the branch too. But
now it saves me the revert ;)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49
producing (after a series of database queries) an empty
tile. Compared to that, the cost of having a 116 byte file lying around
is rather small!
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev mailing list
dev
like this that could be employed. Can you tell me if these
optimizations make sense, and where I can find documentation of how
others have implemented stuff like this?
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev
Hi,
Stefan Keller wrote:
What about storing the object ID (and the link properties) directly in
the OSM object?
Wasn't the idea of *not* polluting the OSM database with external
reference data at the very core of Jaak's proposal?
Bye
Frederik
--
Frederik Ramm ## eMail frede
Hi,
mmap uses a file but acts as if it were direct-access memory, so
your system must have a large enough address space. This has nothing to
do with the amount of physical memory.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
On 08/30/11 11:50, John Smith wrote:
osm2pgsql doesn't have any code to check for memory allocation
failures and to deal with it in a sane way
The error message discussed here is not a segfault, but an out of memory
condition reported by the PostgreSQL client library. It has nothing to
some thorough investigation and I always hoped that
someone more familar with that part of the code (hint, hint) would find
the time to have a look ;)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
dev
this perhaps make these things go away elegantly?
Personally I abhor multithreading for the complexity it brings at
(usually) little gain compared to simply forking a few worker processes
but of course YMMV especially if you want tight communication between
workers.
Bye
Frederik
--
Frederik Ramm
simplifying data
models, too?
Your code does not seem to properly support UTF-8 (it assumes that keys
and values cannot be longer than 256 bytes whereas a 256-character UTF-8
string can be over 1kb in size).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
On 09/21/11 13:13, Erik Johansson wrote:
A bit off topic: I just tried overpass and was surprised that the
default seems to be to strip the version and date, I'm not so keen on
that feature.
Thinking about this, I like the stripping of the version number.
We're having a lot of trouble
Hi,
On 09/21/11 14:01, Serge Wroclawski wrote:
Doing so also precludes merging results with any existing OSM database
though. You can't have an extract then update via a service which
strips version numbers.
If you need versions in your extract. If your extract is supposed to
contain only
701 - 800 of 1434 matches
Mail list logo
