; As the update interval for Geofabrik is 24 hours, should I amend this
> value in the configuration.txt file to suit:
> maxInterval = 3600
It does not make a difference; any maxInterval between 1 and 86400
should behave the same, as each would pick exactly one update per run.
Bye
Frederik
--
as we did before.
This tripped up osmosis and also older versions of osm2pgsql (<= 0.94).
The pbf files are replaced with old-style, compatible files now.
Nightly updates and bz2 files were not affected since they don't use the
PBF format.
Bye
Frederik
--
Frederik Ramm ## eMail frede.
Hi,
On 01/11/2017 10:30 AM, Frederik Ramm wrote:
> SEVERE: Thread for task 1-read-xml-change failed
I was a bit over-eager in shortening the stack trace. Full detail:
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse
xml file x.osc. publicId=(null), systemId=(n
(build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
I have uploaded the two .osc files here:
http://www.remote.org/frederik/tmp/osmosis-bug-try-read-xml-change-write-null-change-on-these-files-which-differ-only-by-one-line.zip
I'd be interested i
> Osmosis?
Osmosis includes bzip2 support so it could decode the .bz2 itself but
since Java bzip2 is much slower than the standalone commandline program,
the version with bzip2 in the pipe is usually recommended.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09
Hi,
On 10/10/2014 10:49 PM, Walter Nordmann wrote:
just call osmosis with host=localhost:15432
Oh dear, that was probably the reason the port thing was never
implemented - because it is so simple to embed it in the host. Should
have thought about that sooner ;)
Bye
Frederik
--
Frederik Ramm
on a website explaining
that the diffs generated by Geofabrik are not meant for direct
consumption by osmosis with a big value on maxInterval ?
I'll do that.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
if that problem is worse than the one we have now!
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
.
There might be more...
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
0.800E+01 0.2000E+01
0.800E+01 0.8000E+01
0.200E+01 0.8000E+01
0.200E+01 0.2000E+01
END
END
Bye
Frederk
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
is there anyone on this list who runs a full OSM replication server
with Osmsois (i.e. import a full history planet file, keep both historic
and current tables, and regularly apply diffs, all using the apidb
schema)?
I would be interested in timings for initial import and diff
plane code that stitches pipelines together etc.
... maybe the approach you are sketching would also allow one to somehow
hack together shortcuts that would allow the building blocks to be
used without anything not necessary for the task at hand.
Bye
Frederik
--
Frederik Ramm ## eMail frede
Igor,
On 02/18/11 11:40, Igor Podolskiy wrote:
just a random thought: what's wrong with using --dataset-bounding-box?
Importing the planet file into a database and doing a bunch of queries
against is equivalent to creating a single disk buffer for all bb tasks
(the database _is_ the disk
Scott,
On 02/18/11 14:15, Scott Crosby wrote:
I used two bitsets for every output file. One indicating which nodes
were already output and another (built when processing ways)
indicating what node ID's were missed and will need to be grabbed on
the next pass. I have another two pair of bitsets
on the same file in windows?
I'll have to defer that to Henning - I am not sure if anyone has even
built pbf2osm on Windows?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis
have development environment on windows to do any experiments of my own.
Same here although I might be able to conjure something up on an old laptop.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis
Hi,
Peter Körner wrote:
I planned to do sth. for this tomorrow:
Download the current europe.osm.bz2, convert it to pbf.
Download the current europe.osm.pbf
Great. - User aighes on talk-de seems to be trying out the same with
today's files.
Bye
Frederik
--
Frederik Ramm ## eMail frede
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
] junit.framework.TestListener:
addError(testProcessBoundContainer1, null)
[junit] junit.framework.TestListener:
endTest(testProcessBoundContainer1)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
improvement at a relatively low cost.
1. Any comments?
2. Anyone done something like that already?
3. Is any of Osmosis' internal storage mechanisms suitable for buffering
relations in this way or do I have to invent something new?
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org
Hi,
Markus wrote:
bin\osmosis.bat -–wxc update.osm.gz
You'd have to do a
bin\osmosis.bat --rri --simc --wxc update.osm.gz
or if you want to apply it to a planet file directly,
bin\osmosis.bar --rri --simc --rx planet.old.osm.gz --ac --wx
planet.new.osm.gz
Bye
Frederik
Brett,
Brett Henderson wrote:
I haven't created a 0.36 detailed usage page on the wiki yet but will do
so before releasing. There are a few other random goodies in the latest
development release that I'd like to release in the near future.
Will there be significant changes in ordinary
steps while still testing the
process.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
. That perl script either supports 0.4 in its
current form, or maybe you'll have to check out an older version from SVN.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev
in importing, not quicker in using)? I.e. you won't
have a linestring to base your GIST index on if you use that as intended.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev
=-Djava.io.tmpdir=/my/pretty/little/tempdir
before you run it.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Hi,
Ibrahim Bouchrika wrote:
Your idea seams nifty, although it's giving an error on the --rx
command. I don't know Osmosis well enough to figure out where the error
comes from. Is it just an error in the syntax or is it because of the
osm-file?
Caused by: org.xml.sax.SAXParseException:
.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
version of all tasks by
adding -0.5 to their name (--bounding-box-0.5 etc.)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org
Brett,
Brett Henderson wrote:
There are no major new features, just an assortment of bugs
That's how we love our Osmosis ;-)
Bye
Frederik
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Hi,
Jens Lehmann wrote:
A solution would be to include it in the planet or provide it as a
separate file, which can be loaded into the database.
Well it isn't even in our central database so it would have to be
computed at the time we dump the planet file which already is an
expensive
Hi,
Walschlager, Gerard wrote:
I appreciate your quick response! I am not surprised by your answer.
Any idea on how much disk space would be required by a PostGIS
database that would hold the entire planet.osm file data?
I think it would be between 100 and 150 GB for either schema; but only
Hi,
Walschlager, Gerard wrote:
You mentioned that osm2pgsql needs more RAM (16GB+ during
import). Do you know how much RAM would be required for normal
lookup and rendering usage with either slim or non-slim usage?
For normal lookup it doesn't make a difference. It should run on a 4 GB
Hi,
Walschlager, Gerard wrote:
The bottom line for my investigation of mapping tools is that I need
to have a local database of the world to perform lookups and
rendering of maps on a standard Windows based desktop computer in a
reasonably quick fashion (i.e. pan/zoom operations complete in 1
.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
still serving active connections to the old database.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Pipeline
entities are not sorted
This seems to be the problem. If you insert a --sort (with some
Osmosis versions you may need --sort-0.6 after *each* --rx spec then
it should work.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
to
|
|+-+
|| |
|| |
|+-+
|
|
Even if you know where the clipping boundary is, you cannot extend the
object towards that boundary properly because you are missing the nodes
beyond the boundary.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Hi,
Simon Nuttall wrote:
2010/1/10 Simon Nuttall simon.nutt...@gmail.com:
I think both these points are more a message for geofabrik.de than me
because I'm using the diff's downloaded from their site.
Sorry, I wasn't clear, I meant to say that CycleStreets uses the
ireland and
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
which do not have to be closed themselves, they only have to
form a closed ring. It will certainly be hard (but certainly not
impossible) to do this with SQL alone.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
probably not live long because its inventor would be likely to
lose interest. Yet you produced something that profoundly influences the
way most of us work with OSM. Hats off to that!
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
resposible for this because I recently changed
the sorting function to treat something with version=x+1 as larger
than something with version=x, instead of equal?
(SVN r18230, change to EntityByTypeThenIdComparator...)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008
in question were an error in somebody's
automated import and have been meanwhile fixed by Lennard (they
contained the same element over and over).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
osmosis-dev
Hi,
Frederik Ramm wrote:
I thought about simply patching Osmosis to use an integer but was
informed by Jon Burgess that osm2pgsql (which is next in my toolchain)
would carp on 65k members as well
Turns out osm2pgsql in its default config allows only up to 32767 members.
Bye
Frederik
Hi,
Brett Henderson wrote:
This was necessary in order to process replicate diffs which sometimes
contain the same object twice, causing the old implementation to
complain about change streams not being sorted (as being sorted,
for Osmosis, means that every object has to be greater than
Hi,
Karl Newman wrote:
If the fault does lie
with the bzip2 code, then I'm surprised you're the only one that's reported
a problem so far.
Nobody in their right mind lets Osmosis compress or decompress bz2 ;-)
Bye
Frederik
___
osmosis-dev mailing
47 matches
Mail list logo
