-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 14-07-12 00:27, Paweł Paprota wrote:
I wonder if for such a basic/welcoming editor it would be good to
consider performance as a factor. Solution from Google Map Maker
looks good at a glance (I have not used it too much) - you have to
select
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11-07-12 17:10, Grant Slater wrote:
Summary: Please stop Imports, Automated Edits, Bulk edits Bots
until the redaction process has ended.
What is your ETA?
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10-07-12 21:18, Even Rouault wrote:
Following the recent brainstorming with Jukka, I've pushed into
trunk a driver to read OpenStreetMap .osm / .pbf files .
Is this driver able to replace tools such as osm2pgsql? Hence does it
integrate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 27-06-12 23:12, Robert Joop wrote:
Why unreadable? What viewport setting do you use?
A mapquest widget is used within a native app.
angles I didn't saw you comment on was: going svg.gz all the
way. Rendering tiles in SVG, doing so with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 26-06-12 23:05, Frederik Ramm wrote:
I have had some people asking whether I could supply them with
Retina map tiles. Retina is an Apple brand name for higher
resolution displays, and these users tend to mean tiles with twice
the
Hi,
Last night Archive.org has set up a collection to facilitate tile serving
from Archive.org. We can experiment on what the best structure of this
would be. Anyone with interest in this subject please contact me.
Stefan
___
dev mailing list
On 15-04-12 19:27, Sven Geggus wrote:
What is the magic with this? How can I convert something like
11/0/0/66/61/112.png
The Dutch tile server does do metatiling for rendering, but writes it
out as static png files, served out with Cherokee as static webserver.
It is a minor change to
On 15-04-12 22:58, Sven Geggus wrote:
Basically I'm looking for a script which will convert my mod-tile
directory to something which can be served by a static Webserver.
So nothing 'on the fly'? Only postprocessed?
Stefan
___
dev mailing list
On 20-03-12 22:04, elbereth wrote:
I followed the mod_tile tutorial in the OpenStreetMap Wiki
(http://wiki.openstreetmap.org/wiki/HowTo_mod_tile). My server runs Debian 6
with g++, I got the following error, while trying to compile mod_tile.
I don't see your error, but if you are running
On 13-03-12 22:14, Peter Körner wrote:
Am 13.03.2012 16:24, schrieb Grant Slater:
Sincerely
Grant Slater
On behalf of the OpenStreetMap sysadmin team
Thank you very much for keeping things running! You're the ones, that
keeps our great project running and running and running and running...
On 14-03-12 01:43, Grant Slater wrote:
We have a machine ready to be a slave, but are not yet ready to enable
it. We are planning this for mid/late April timeframe.
Very good to hear :)
Stefan
___
dev mailing list
dev@openstreetmap.org
On 12-03-12 22:14, Chris Hill wrote:
On 12/03/12 20:40, Morten Olsen lysgaard wrote:
I'm running a sister project of OSM, OpenAviationMap.
^^
My first reaction is that airspace does not belong in OSM.
Chris, please read what he actually writes.
But now we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 03-01-12 09:21, Philipp Borgers schreef:
We can provide rack space and bandwidth for at least one server
here in Berlin. We also have some servers we can contribute to the
project but they are not that powerful.
I hope you can put your offer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Archive.org replied positively; update on the wiki.
http://wiki.openstreetmap.org/wiki/TileCDN
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The basic outline;
- - People seem to love using tile.openstreetmap.org for any of their apps
- - Apps get blocked for various reasons, contributing back is difficult
- - OpenStreetMap wants to be the leading provider of such data
I would propose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have just summerized the e-mail by Mike, and created a wiki page the
follow up the status:
http://wiki.openstreetmap.org/wiki/TileCDN
Op 30-12-11 18:23, Lynn W. Deffenbaugh (Mr) schreef:
I would love to monitor such discussion and contribute if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-12-11 12:45, Simon Poole schreef:
PS: the server is a Hetzner EX-5 so please be nice to it and don't
stress it too much :-)
If this is really the ODBL only-map. Then I have some doubt about its
correctness; OSM has some functional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-12-11 15:19, Simon Poole schreef:
You did read the information displayed before you viewed the map?
:-)
Actually I did:
hide objects that were created by mappers that have not agreed to the
OSM contributor terms, exceptions below
So that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 19-12-11 02:55, Tom Sparks schreef:
Is their a php port of the OSM api? if not what are the bare
minimum needed to support polatch?
Yes, I did coded one once...
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 19-12-11 02:55, Tom Sparks schreef:
Is their a php port of the OSM api? if not what are the bare
minimum needed to support polatch?
Ah wait... you want a server, not client.
I only wrote 0.5 in plain C...
Stefan
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 17-09-11 23:46, klo...@gmail.com schreef:
Would it be possible to add the CORS HTTP header:
Access-Control-Allow-Origin: * to the OSM tileserver when a tile is
requested?
Probably you will need the other two headers as well.
Stefan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hey Steve,
Op 18-09-11 20:27, Steve Coast schreef:
What are the other headers? I thought it was just the one
mentioned.
It is browser dependant, firstly;
- - OPTIONS request should be allowed (if that results in a 405/503 =
fubar)
Then the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 18-09-11 21:02, andrzej zaborowski schreef:
I can try preparing a mockup of osm.org with that option if there's
interest.
If I enable this on tile.openstreetmap.nl, you could try it out for
The Netherlands ;)
Stefan
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Peter,
Op 18-08-11 12:11, Peter Körner schreef:
Will it be in the planet.osm? If not, how are tile-providers are
supposed to draw an icons for museums?
Like they do now for coastlines... there are external datasources and
they are already in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 15-08-11 22:57, Jaak Laineste schreef:
My proposal is in http://wiki.openstreetmap.org/wiki/OpenMetaMap ,
any positive and negative comments (especially help to actually
implement it) is most welcome.
I think Google translate shows you are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 22-05-11 17:12, Philippe Coent schreef:
I am running a mod_tile/renderd/postgis map OSM server.
I rendered all the meta tiles using the render_list tool.
I can then convert those .meta files into .png using the provided tool.
On the Dutch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 21-05-11 12:52, Frederik Ramm schreef:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 21-05-11 16:52, Jochen Topf schreef:
If we use unsigned ints we have some more time. Problematic would only be
a few cases where negative IDs are currently used (like in JOSM for data
thats not yet uploaded to the server). But it seems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 22-03-11 08:33, Kai Krueger schreef:
I'll possibly be able to mentor such a project, although I know little about
the code of any of the editors, so I'd be less able to help on that side of
things.
Since I was the mentor of the last project,
On Mon, 10 Jan 2011, Matt Amos wrote:
it seems postgres 9 isn't able to do temporary table creation on
hot-standby servers [1]. maybe this is something that'll be fixed in
future versions (but it doesn't seem to be on the TODO [2]) or maybe
it's an opportunity to put a bounty to good use.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 18-12-10 11:53, David Paleino schreef:
Hello people,
I'm writing a parser in C# for PBF dumps. However, I'm having issues with the
Delta-{en|de}coding.
http://git.openstreetmap.nl/index.cgi/pbf2osm.git/tree/src/main.c#n588
Maybe that helps?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 16-12-10 09:22, Frederik Ramm schreef:
If someone feels like (a) re-implementing this in C
I think Mitja did this in the GSoC program this summer (the cutout
thing). It would be valuable to figure out a way to do 'proper' full
ways and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 16-12-10 22:10, Peter Körner schreef:
The osm2pgsql scheme does not store meta information (version, creator,
timestamp), which are required to create valid .osm files.
Valid sounds like someone updated a XSD file already?
On Wed, 15 Dec 2010, Frederik Ramm wrote:
On 12/15/10 08:53, Stefan de Konink wrote:
It has been done in C already :) By different people, so what are we
waiting for :)
If there's a working instance that supports the XAPI protocol it should be
added to http://wiki.openstreetmap.org/wiki
On Wed, 15 Dec 2010, Frederik Ramm wrote:
But then again: XAPI has been written by a single person, in (what we
consider) an esoteric programming language, in their spare time. So if
someone really wanted to do it better, it should be a breeze to implement the
same, or even an improved,
On Sat, 11 Dec 2010, Wyo wrote:
To have as many as possible proxies running in the internet means to stick
with technologies easily available. That limits the choice almost entirely to
a PHP/MySQL solution, at least for the beginning.
DBSlayer is actually what you want here. Discussed before
Hi all,
I would like to invite anyone that would like to volunteer in osm2pbf
c-development to join us for a tonight coding session. I suggest #osm2pbf
We will build the basic building blocks, analyse documentation, and
hopefully compair output to osmosis, in speed and what it did produce.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Mike,
Op 11-12-10 16:26, Mike Dupont schreef:
I have done some work on an osm parser in c
https://code.launchpad.net/~jamesmikedupont/+junk/EPANatReg
and pbf reader in c,
https://github.com/h4ck3rm1k3/OSM-Osmosis/
you might find it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 11-12-10 22:05, Anthony schreef:
On Sat, Dec 11, 2010 at 9:58 AM, Stefan de Konink ste...@konink.de wrote:
I would like to invite anyone that would like to volunteer in osm2pbf
c-development to join us for a tonight coding session. I suggest
On Wed, 8 Dec 2010, SteveC wrote:
Transiki is like OSM but stores magical transit data. It's approximately,
nearly, at 0.1. It looks and feels very similar to OSM internally. It's written
in rails, it's API looks similar and so on. You can think of it as a baby OSM.
I'm a little overwhelmed
On Wed, 8 Dec 2010, Mike Dupont wrote:
realtime could be provided by such a thing as GEORSS
http://www.georss.org/Main_Page
where you show either, where the things SHOULD BE, or another feed
with where they have last been reported to have been.
Our design documents include GeoRSS feeds over
On Wed, 8 Dec 2010, Mike Dupont wrote:
Ok Stefan, I am sorry that I have not read about all these things you
guys have been doing.
please tell me, how do you get all this data? Is there a way to
extract all the transit data from osm in an easy way? that would be a
good test for transiki to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 08-12-10 21:30, Mike Dupont schreef:
On Wed, Dec 8, 2010 at 9:22 PM, Stefan de Konink ste...@konink.de wrote:
But please understand that timetables is something that is in the process of
being phased out anyway... and routes are basically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 08-12-10 22:13, Wyo schreef:
And how do I bring an aquivalent error message onto the screen when this
happens?
You don't because you only know that someone went wrong. But not what
actually did.
-BEGIN PGP SIGNATURE-
Version: GnuPG
On Wed, 1 Dec 2010, Anthony wrote:
On Tue, Nov 30, 2010 at 11:03 PM, Anthony o...@inbox.org wrote:
On Tue, Nov 30, 2010 at 8:29 PM, Stefan de Konink ste...@konink.de wrote:
If any of gzip/bzip2/lzma in the general give better compression ratio's
(20% smaller), then this compression scheme
On Wed, 1 Dec 2010, Anthony wrote:
Did you benchmark what pbf + lzma did or did you embed lzma in osmosis?
xz uses lzma. I made an uncompressed pbf file (florida.osm.rawpbf)
and then compressed it with xz (florida.osm.rawpbf.xz). This isn't
the same as making a pbf file which uses lzma, but
On Wed, 1 Dec 2010, Anthony wrote:
Yeah, but your lead basically shows we are talking about more than 10%...
Yeah, probably, but at the expense of more complicated code, greater
memory usage, etc.
The hole process is IO-bound... memory is used anyway to overcome the IO
issues...
I'm
On Wed, 1 Dec 2010, Anthony wrote:
Not in an embedded system, which is where a small difference like 10%
is going to matter.
Please elaborate? Either the memory is used for a block cache or for the
program.
I'm interested now in seeing how the full history compression goes,
though. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 01-12-10 17:30, Anthony schreef:
Anyway, I'm probably completely wrong about this. Sorry.
I guess the fastest way to verify all this is someone that adds the LZMA
and BZ2 library to java and check in osmosis. Your numbers give me the
On Tue, 30 Nov 2010, Jochen Topf wrote:
The PBF format supports three compression types: zlib, lzma, and bzip2. Do
we have to support all of them? What is the currently existing software
using?
IMHO it would make more sense to just define one and stick with it. Easier
to implement for
On Tue, 30 Nov 2010, Tim Teulings wrote:
Hallo!
Why this mentality? It is trivial to implement a decompression algorithm
and some work better than others. Sounds like complaining about stuff you
don't have to care about.
I would not implement decompression myself, I have better things to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Op 30-11-10 20:49, Frederik Ramm schreef:
Stefan de Konink wrote:
This is the place for the 'too little, too late'. We are beyond the
point of 'what' the bitstream should look like: you ought to handle
what is defined now
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 30-11-10 21:26, Jochen Topf schreef:
Sometimes it is useful to read ways before nodes or relations before way or
nodes. With the XML format this is not really possible, but with the PBF
format it could be reasonably easy if we store the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Scott,
Op 01-12-10 00:41, Scott Crosby schreef:
The real question is does supporting bzip2/lzma offer advantages that
are commensurate with the added implementation complexity, not just in
pbf2osm but in every other reader too.
If any of
On Tue, 16 Nov 2010, Jon Burgess wrote:
Are the errors you see consistent between runs?
Basically 'still' importing now. I can possitively confirm that this is
because of 'out of memory' situations. You may wonder if instead of using
memory osm2pgsql shouldn't go for a mmaped areas (so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
After 4 unsuccesfull in osm2pgsql runs, and today after md5 validation.
I am pretty sure that the file that I have downloaded is complete.
ea628ba9912e6d33ef65d35b7cbe6823 planet-latest.osm.bz2
But osm2pgsql reports:
Reading in file: -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 15-11-10 23:38, Jon Burgess schreef:
Have you changed anything recently?
Like what, it was a fresh download, and I have never used PostGIS on my
system.
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using
Is it possible to generate them and be placed on planet.openstreetmap.org
?
Stefan
Op 14 nov 2010 om 05:59 heeft Scott Crosby scro...@cs.rice.edu het
volgende geschreven:\
On Thu, Nov 11, 2010 at 4:06 AM, Stefan de Konink ste...@konink.de
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 14-11-10 23:13, Scott Crosby schreef:
On Sun, Nov 14, 2010 at 4:54 AM, Stefan de Konink ste...@konink.de
mailto:ste...@konink.de wrote:
Is it possible to generate them and be placed on
planet.openstreetmap.org http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Did anyone already made an attempt to generate a (full) Planet PBF file?
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On Mon, 1 Nov 2010, Dane Springmeyer wrote:
+1 on pure C++. I assume we'd only need the protobuf C++ headers then,
instead of both the c++ and c?
Please team up with Mercator (Chris) because now we have C version, and
C++ was already requested by many.
Stefan
On Mon, 25 Oct 2010, Chris Browet wrote:
Sure. I don't think the C - C++ will be problematic.
It might be, because a completely different library/code generation
program is used. Anyway, I still need to look into that.
Things that I must do for Merkaartor:
- Take the logic out of main()
of
Mapnik ;)
STefan
On Sun, 24 Oct 2010, Hartmut Holzgraefe wrote:
On 09/24/2010 10:10 PM, Stefan de Konink wrote:
As far as I can see with a quick look we are in a state of functional.
[...]
(you need to have protobuf-c installed, to compile it, see the Makefile
for that)
took a bit
On Mon, 25 Oct 2010, Chris Browet wrote:
Would you mind if I re-use your code to implement a pbf reader in
Merkaartor?
Not at all, I just hope that everything that is coded now is correct, and
you are able to track 'potential' further improvements.
The current plan is also to equip mapnik
Plan is first to release native support for osm2pgsql.
Stefan
Op 18 okt 2010 om 11:59 heeft Peter Körner osm-li...@mazdermind.de
het volgende geschreven:\
Am 26.09.2010 17:14, schrieb Stefan de Konink:
When this tool is polished enough (must include some bbox'ing then)
we
can think
On Sun, 17 Oct 2010, Frederik Ramm wrote:
The *** case couldn't be tested: Error unpacking PrimitiveBlock message.
The offending file is at http://www.remote.org/frederik/tmp/by-none.osm.pbf
if someone wants to check what's wrong with it.
Gonna fix that :)
Stefan
On Sun, 17 Oct 2010, Stefan de Konink wrote:
On Sun, 17 Oct 2010, Frederik Ramm wrote:
The *** case couldn't be tested: Error unpacking PrimitiveBlock message.
The offending file is at
http://www.remote.org/frederik/tmp/by-none.osm.pbf if someone wants to
check what's wrong
On Sun, 17 Oct 2010, Stefan de Konink wrote:
message 'PrimitiveBlock': missing required field 'stringtable'
Error unpacking PrimitiveBlock message
(gdb) print *hmsg
$3 = {base = {descriptor = 0x406740, n_unknown_fields = 0,
unknown_fields = 0x0}, bbox = 0x0, n_required_features = 0
On Sun, 17 Oct 2010, Frederik Ramm wrote:
The *** case couldn't be tested: Error unpacking PrimitiveBlock message.
The offending file is at http://www.remote.org/frederik/tmp/by-none.osm.pbf
if someone wants to check what's wrong with it.
I have now explicitly said raw_size in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 17-10-10 19:42, Frederik Ramm schreef:
(My dislike of git stems largely from ignorance and is likely to vanish
over time. At the moment I have grown used to the one-stop-shop that is
our SVN; with git I miss the option to say check out all OSM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Frederik,
Op 17-10-10 20:11, Frederik Ramm schreef:
(1) every project will have to have a maintainer who decideds what gets
pulled into trunk - this introduces more formality than we have now;
Maybe our data is informal. I rather not have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 17-10-10 22:13, Scott Crosby schreef:
I left the raw_size unset, and you're getting the default value of 0.
If this is by design, make it explicit on the wiki page (aka: this value
is unset if no compression is used)
I fixed it already... but
On Sat, 16 Oct 2010, Scott Crosby wrote:
Also, can you give me the URL for the source code for pbf2osm to check that
a few edge-cases are correctly handled?
http://git.openstreetmap.nl/index.cgi/pbf2osm.git/
Stefan
___
dev mailing list
On Sun, 10 Oct 2010, Chris Browet wrote:
I think it's desirable. They'll still be available in the object history,
and the removal is
So do I.
I wonder why a bot hasn't been run to remove them all.
I guess that would slim the planet measurably...
And increase the database considerably. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 30-09-10 06:30, Scott Crosby schreef:
Also Osmosis currently implements deflate, not bzip2/lzma. (At the
time of writing I implemented bzip2 as well, but couldn't test it.)
If I can find a lzma/bzip2 java code, its ready to plug
On Thu, 30 Sep 2010, Scott Crosby wrote:
I proposed exactly this for the mkgmap splitter. If you're going to do this,
can I propose a tweak where you can output thousands of files
simultaneously? The differences are minor: Instead of tracking if a
node/way/relation was output or was missed with
On Thu, 30 Sep 2010, Scott Crosby wrote:
From what I observe now the bottleneck seems to be actually protocol
buffers, while my output code can become slightly faster.
This would imply that doing binary changesets isn't a critical necessity.
You asked where the bottleneck is, for XML
On Thu, 30 Sep 2010, Frederik Ramm wrote:
Stefan de Konink wrote:
When this tool is polished enough (must include some bbox'ing then) we
can think about osm2pbf.
Speaking of polished: The program currently produces invalid XML because
and are not escaped, leading to lines like
Yes
On Wed, 29 Sep 2010, Anthony wrote:
In addition to and , you need to escape . planet.c also escapes
. It uses character references for each (quot;, amp;, lt;, and
gt;). planet.c also escapes carriage return, line feed, and tab, as
#13;, #10;, and #9;. AFAICT it is legal to include these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Peter,
Op 26-09-10 17:00, Peter Körner schreef:
Am 24.09.2010 22:10, schrieb Stefan de Konink:
Or the (static) 64bit version:
http://mirror.openstreetmap.nl/pbf2osm64
p...@maps:~$ pv -cN 'pbf-input' /osm/data/planet-extract/hessen.osm.pbf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
As far as I can see with a quick look we are in a state of functional.
Tweaking will be done of course, especially because this version is only
a pipe.
cat test.pbf | pbf2osm output.osm
You can check it out at:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-09-10 23:20, Anthony schreef:
Some quick notes...
Had to create ../OSM-binary/src
Had to download the .proto files and move them into ../OSM-binary/src
Had to make ../external and ../external/lib
Make sure you have the newest version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
As annouced some days ago I would start with the development if nobody
stepped up before Friday. Nobody did, so I will do so.
Language of constraint is C, we will most likely not use any external
dependancies. So porting to different platforms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-09-10 02:03, Anthony schreef:
On Thu, Sep 23, 2010 at 6:18 PM, Frederik Ramm frede...@remote.org wrote:
Language of constraint is C, we will most likely not use any external
dependancies.
Well you won't get around the Google Protobuf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-09-10 03:44, Stefan de Konink schreef:
unsupported tag 4 at offset 16
Error unpacking compressed HeaderBlock message
(Generated with osmosis...)
Never mind, I expected protobufs to be more robust ;) It isn't. Fixed.
Stefan
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-09-10 04:26, Scott Crosby schreef:
What was the problem and the fix?
The problem was that I assumed that after a succesful inflate nothing in
my inflate buffer could have gone wrong. But I was actually placed on
the end of that buffer.
So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 24-09-10 04:58, Stefan de Konink schreef:
For whats worth, currently I'm able to decode the 'fileformat', doing
deflate decompression. So still some stuff to go, but I understand the
basics now... so I'm a happy farmer.
Small status update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 22-09-10 14:34, Frederik Ramm schreef:
I'm sure we'll get a pure C/C++ implementation sooner or later; even so,
there certainly will be people who don't feel like installing it.
If noone steps up for the reference implementation before Friday
On Wed, 22 Sep 2010, Frederik Ramm wrote:
My guess is that 95% of people who use these files process them either with
osmosis, or mkgmap, or osm2pgsql.
Don't make the same mistake as with disabling the gazetteer. Legacy can be
useful, is there currently a plain C implementation with a
On Sun, 19 Sep 2010, Ian Dees wrote:
Has anyone started playing with Postgres 9.0 and OSM data? I'm particularly
interested in the streaming replication system they've introduced.
Only tested how PostGIS was working, other than 'it works' with some
patches, not really having input.
Stefan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 27-08-10 20:50, Marco Lechner - FOSSGIS e.V. schreef:
I'm confused and asking for enlightenment.
Not all data might as well aligned as you might think ;) A lot of
deletes and updates in a table can make it pretty sparse.
Stefan
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 15-08-10 16:31, bernhard zwischenbrugger schreef:
Hi all
My next project is an XAPI map.
You can see a prototype at:
http://www.khtml.org/osm/v0.76/examples/xapi.html
It is possible to make a global search for
power_source=nuclear
On Wed, 4 Aug 2010, Frederik Ramm wrote:
Otherwise people might just put in a lot of work for nothing.
Obviously not true, since the data will be available in the CC-BY-SA
output.
Stefan
___
dev mailing list
dev@openstreetmap.org
On Mon, 2 Aug 2010, Lars Francke wrote:
Matt Amos was so nice to run the history export again.
The result is available here:
http://planet.openstreetmap.org/full-experimental/full-planet-100801.osm.bz2
and it's grown from 13 GB in February to 17 GB. The regular planet has
grown from 8 to 10 GB
On Sun, 1 Aug 2010, Frederik Ramm wrote:
A lot of time is spent just reading from, and writing to, disk and parsing
XML. Running the whole thing with .gz files doesn't make a big difference -
saves some disk i/o, adds some CPU time, doesn't change XML parsing overhead.
I'm sorry but the
On Sun, 1 Aug 2010, Anthony wrote:
On Sun, Aug 1, 2010 at 6:00 PM, Stefan de Konink ste...@konink.de wrote:
If the binary format can pack our doubles (lat/lon)
lat/lon is stored as a double? I always use an int (and
divide/multiply by 1000).
http://wiki.openstreetmap.org/wiki
On Wed, 21 Jul 2010, 80n wrote:
Right now, it seems to me that tracing twice might be the most effective
solution.
The simple solution obviously would generate SQL from a diff file, that
can by pass the api. This could be relatively fast.
Stefan
On Wed, 21 Jul 2010, 80n wrote:
High performance is not a requirement. Fidelity of merging edits that are
potentially conflicting is important. There will be some divergence between
the OSM dataset and the once that is being created.
Actually it is, the faster the transactions can be pushed
On Wed, 21 Jul 2010, 80n wrote:
It's going to take several months to prepare *before* it even meets OSM, so
speed really isn't a requirement.
So what you actually are looking for is a tool that can interactively
fastforward changes? As you would have with a source code versioning
system?
On Tue, 20 Jul 2010, John Smith wrote:
I've seen schema and such on the wiki, but nothing putting it all
together like some of the mapnik/mod_tile/etc tutorials.
If nothing exists I'll start documenting it as I go...
I wrote a complete read/write API in C.
1 - 100 of 564 matches
Mail list logo
