On Wed, Mar 07, 2012 at 04:33:28PM +0100, Peter Körner wrote:
> Am 07.03.2012 15:57, schrieb Jochen Topf:
> >Hi!
> >
> >I have been working on writing a substitution for the aging coastcheck
> >program.
> >It is not finished yet, but maybe somebody wants to play
er of magnitude faster than
coastcheck does it.
More info in my blog at
http://blog.jochentopf.com/2012-03-07-osm-coastlines.html
Code at https://github.com/joto/osmcoastline .
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-3
On Tue, Mar 06, 2012 at 10:44:45AM -0600, Martijn van Exel wrote:
> On Tue, Mar 6, 2012 at 7:42 AM, Jochen Topf wrote:
>
> > On Tue, Mar 06, 2012 at 01:31:31PM +0100, npl wrote:
> > > TagInfo-like systems (aggregating big data and creating statistics)
> > > could de
even more inefficient. Then to keep it going we invent more
and more technology around it. Oh well, I liked Osmarender, spent quite a
lot of time improving it and rendering maps with it. Sometimes its not about
being efficient. :-)
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jo
we should move towards a model where they can be expressed as proper areas
and until then use type=multipolygon.
There are different details on how public transport routes, hiking trails etc.
are handled, but it all comes down to an ordered list of ways
which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
> ___
> dev mailing list
> dev@openstreetmap.org
> h
On Tue, Feb 07, 2012 at 11:33:56AM -0600, Martijn van Exel wrote:
> Is the input file name accessible within OSMJS?
No. But extra arguments are in the global Javascript array "argv".
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +
order to
> show the tooltip.
Yes. Unfortunately that would need more digging around other people's
Javascript library code than I am willing to do at the moment. If somebody
figures out a way to do that in a reasonably clean way, that would be great.
Jochen
--
Jochen Topf joc...@remote
http://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_February_2012
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
the PBF writer.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
1.42.0.1ubuntu1
> libprotobuf-lite62.3.0-4ubuntu2
> protobuf-compiler2.3.0-4ubuntu2
>
> I also tried updating to latest OSM-binary but I get the same error
> compiling tagstats.
>
> Any suggestions?
>
> D
>
> _
appen in practice.
So if you see this problem, upgrade to a newer version of Osmium.
And if you have implemented a PBF writer, you should probably check whether
it suffers from the same or similar problem.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-3
based on the input file.
All extra arguments from the command line are available in the global
Javascript array named "argv".
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@
array that
size, but I could imagine that its quite a bit.
Jochen
On Mon, Nov 21, 2011 at 10:16:25AM -0700, Martijn van Exel wrote:
> Date: Mon, 21 Nov 2011 10:16:25 -0700
> From: Martijn van Exel
> To: Jochen Topf
> Cc: Hermann Peifer , ThomasB ,
> dev@openstreetmap.or
On Mon, Nov 21, 2011 at 10:33:40AM +0100, Hermann Peifer wrote:
> On 21/11/2011 08:13, Jochen Topf wrote:
> >On Sun, Nov 20, 2011 at 03:34:27PM -0700, Martijn van Exel wrote:
> >>I also ran into trouble with files of around 40MB or larger. I still
> >>get the same errors
ms thats the same as the end of the program anyway.) So
there is no leak, all memory is accounted for.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
he script you are using? Maybe we can find out if its doing
something that triggers a bug.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
15 October, where osmjs still works fine. The changes in [2] are
> causing the memory allocation trouble with larger .pbf files.
>
> Hermann
>
> [1]
> https://github.com/joto/osmium/commit/61de862b54ffd879034c6f371df99182480fd613
>
> [2]
&
gt; Date: Wed, 9 Nov 2011 08:23:54 -0700
> From: Martijn van Exel
> To: Jochen Topf
> Cc: dev Openstreetmap
> Subject: Re: [OSM-dev] osmjs says 'Killed'
>
> Jochen,
>
> I compiled with the GC flag and can confirm that osmjs's memory usage
> is definitely
e stringtable
implementation and its not entirely clear that this refers to the Java
reference implementation and others might do it differently etc.)
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
__
n a germany extract and sometimes others and don't have
any problem like that. But it could be that the problem only shows up with, say
very long ways, or objects with many tags or so. There could be something
different about the US extract that triggers this. (Or maybe its ju
the proto
file that was missing to the wiki page. But I do agree that the documentation
is not as good as it could be. Still far better than many other parts of OSM.
:-)
What I'd like to see at some point is a better distinction between the PBF
format itself and the reference (and other) implem
ts in PBF reader and writer.
* Lots of other small fixes and cleanups here and there.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
e one used most often. So having
always two relations is conceptually much easier.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Maybe Frederik can help a bit more. He builds the osmium/osmjs on Geofabrik
machines using 10.04 for me. :-)
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Wed, Oct 05, 2011 at 08:20:10AM -0700, Richard Fairhurst wrote:
> Jochen Topf wrote:
> > Thats sounds rather optimistic to me. As far as I know everybody who
> > has thought about a proper area type has given up, because nobody
> > could find a way how it was to be implem
up with a
brilliant plan, because I also do think that we need an area type.
Before we start this discussion here again. Please everybody have a look at the
wiki (http://wiki.openstreetmap.org/wiki/The_Future_of_Areas) and read about
all the things people have already proposed and thought about
ype should be pretty strict and solid, the *tags* is
where we have the typical OSM flexibility.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
when doing this).
You then have a multipolygon with a set of tags, handle it like you would
for nodes and ways, ie. look at the tags and decide where and how to draw
it. Discard any object that only has tags you don't understand.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
change?
I am not sure any of those lead to the problem you describe, but you should
fix them and we'll see how it look afterwards.
Jochen
On Wed, Sep 21, 2011 at 03:48:45AM -0400, Pris Matic wrote:
> Date: Wed, 21 Sep 2011 03:48:45 -0400
> From: Pris Matic
> To: Jochen Topf
>
> However, at some point in the process, they will turn 'random' and become
> garbage. I've been stuck on this issue for awhile, and I'd appreciate any
> advice.
>
> -Pris
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
first few ways are
> fine, then they go crazy:
> http://pastebin.com/Hd2ywgn4
>
> I'd appreciate any suggestions.
If you post your code we can maybe see something.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
different ways of using the mmap handler
for storing node locations: One uses RAM only (if you initialize it without a
filename), the other uses the disk as backing store (if initialized with a
filename).
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-7
hould not make
> a huge difference?
Thats doesn't make a difference in this case.
> BTW, is it already possible to use osmium for full history files? I'm
> not even concerned about doing stuff with geometries, only gathering
> staistics -- ie what have users contributed over
ed 1 bit for each node.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Hi!
Here you can see all cases with only a single node in a way or duplicate
consecutive nodes:
http://tools.geofabrik.de/osmi/?view=geometry&lon=-12.0&lat=25.0&zoom=3&overlays=single_node_in_way,duplicate_node_in_way
Jochen
--
Jochen Topf joc...@remote.org http:
robably with an image, and a description of how it
can be solved. Configuration file snippets, SQL queries etc. can be added to
show examples of the solutions for different kinds of software.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
uffer bufferCapacity=12000
--apply-change --buffer bufferCapacity=12000 --write-pbf $NEWPLANET
This takes about an hour every day on a 800MHz machine.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mail
tirex-master in
> /etc/init.d :
> $ /etc/init.d/tirex-master restart
>
> $ which tirex-master
> /usr/bin/tirex-master
>
>
> Anyone have a clue what might be the reason for "Cannot open master
> UNIX domain socket: No such file or directory" ?
>
> Cheers,
>
change settings
accordingly. Look at the jobs.log logfile for rendering times and success
rate. Experiment with different settings.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
you haven't even got a plan,
just a vague idea?
Please, if you think this is worth working on, then do so. Work on it. Study
the problems, change some software, come up with a plan, try to implement it,
find flaws, rework the plan. Do something.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Mon, May 23, 2011 at 04:18:05AM -0500, Scott Crosby wrote:
> On Sat, May 21, 2011 at 9:52 AM, Jochen Topf wrote:
> >
> > 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 d
e in JOSM for data
thats not yet uploaded to the server). But it seems wasteful to me, to go
to 64bit a year or so earlier than needed to accommodate this case.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
he tag that says that
this is a history file. Just as we are currently discussing for the PBF
version.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
n of .osm).
I would be relatively straightforward to use .osc.pbf and .osh.pbf for the
(still to be specified) PBF versions of those files.
Or we could remove that strangeness and use some other scheme:
.bosm, .bosc, .bosh (b for binary) ?
.pbf, .pbfc, .pbfh ?
Opinions? Ideas?
Jochen
On Mon, May 09, 2011 at 05:21:40PM -0500, Scott Crosby wrote:
> On May 8, 2011 5:21 AM, "Jochen Topf" wrote:
> > Thinking about the inclusing of the invisible-Flag I think we have to step
> > back a bit:
> >
> > There are two use-cases: One is reading an OSM
ity count. Marker blocks only work with sorted
> data. Counts inflate the planet by 1mb and don't really solve the
> problem. What makes 1MB or a marker block worth having
1MB is nothing compared to the size of the planet which grows about 1 GB
every month or two.
> I'm now le
eNodes?
Also protobuf already supports some kind of introspection. I have never worked
with it, because, as Scott says, it doesn't really give you enough information.
But it is there.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
y use case where you would need that, because there is no
relationship between those IDs and anything you are interested in the real
world. If you have a small list of IDs and want to read only those, it could
make sense. But that list had to be very small.
Jochen
--
Jochen Topf joc...@remote.org h
red_feature" or
something else. Its not really a feature. But it would make sense to use this
mechanism.
The PBF documentation would then explain that your are not supposed to set the
visible flag on "current OSM" files and have to ignore its setting when reading
those, but you have to
urrent disk sizes and b) will be eaten up in a few months
of OSM growth. Time savings on the other hand are my biggest issue in most
applications with OSM, because I want to work with data thats as current
as possible.
That being said I would not object to adding an lzma o
object type). This would reduce the overhead on each
block slightly for the price of having an additional block type. I am not
sure which solution is best.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mail
le to add repeated fields. Just be sure not
> to reuse any IDs.
Ok, that makes sense. That leaves the problem with the wrong default. You
can't set a default on a repeated field (I tried and the protobuf compiler
complained). But the default for the visible flag should be "true" to
I only see the option of having the DenseInfoWithVisible message
that supersedes the DenseInfo message and note it in the header that we need
this capability. But I am hoping there is a better solution that doesn't lead
to an incompatible change.
Jochen
--
Jochen Topf joc...@remote.org http://www
Hi!
I have cancelled this workshop due to lack of interest. I'll be at the hack
weekend in Essen, so if anybody is interested in Taginfo stuff, I suggest we
do it there.
http://wiki.openstreetmap.org/wiki/Hack_Weekend_Essen_June_2011
Jochen
On Sun, Apr 03, 2011 at 07:59:56AM +0200, Jochen
ory-efficient than tree/DOM-based parsing.
>
> From my experience the expat-sax immplementation is faster then the
> libxml sax-parser.
I benchmarked it when developing Osmium and for OSM files expat was about 10%
faster than libxml2.
Jochen
--
Jochen Topf joc...@remote.org http://ww
On Thu, Apr 14, 2011 at 03:58:20PM +0200, Peter Körner wrote:
> Am 14.04.2011 14:32, schrieb Jochen Topf:
> >On Thu, Apr 14, 2011 at 12:21:58PM +0200, Peter Körner wrote:
> >>As far as i understood there's still some logic needed to assemble
> >>osm objects from the
On Thu, Apr 14, 2011 at 03:03:00PM +0200, Oliver Tonnhofer wrote:
> On 14.04.2011, at 12:10, Jochen Topf wrote:
> > To make the PBF stuff from Scott easier to use from C++ I have added a
> > Makefile
> > and Debian config in my fork at https://github.com/joto/OSM-binary . Th
On Thu, Apr 14, 2011 at 12:21:58PM +0200, Peter Körner wrote:
> Am 14.04.2011 12:10, schrieb Jochen Topf:
> >To make the PBF stuff from Scott easier to use from C++ I have added a
> >Makefile
> >and Debian config in my fork at https://github.com/joto/OSM-binary . This
>
-dev package.
I have sent Scott a pull request. We'll see how he likes it. :-)
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/lis
t possible? Or could I support you in developing this feature?
>
> Thanks a lot
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
ng all of that yet.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
iling list.
> Google Groups would be an option. Is there something else you could
> recommend?
Maybe becoming an OSGeo project is an option? http://www.osgeo.org/
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
__
On Mon, Apr 11, 2011 at 02:31:19PM +0200, Steven M. Ottens wrote:
> On 4/11/2011 2:01 PM, Jochen Topf wrote:
> >On Mon, Apr 11, 2011 at 12:24:38PM +0200, Steven M. Ottens wrote:
> >>Does Tirex support different projections and tileschema's? I'm
> >No.
> &g
On Mon, Apr 11, 2011 at 12:24:38PM +0200, Steven M. Ottens wrote:
> Does Tirex support different projections and tileschema's? I'm
No.
The "Google" projection and tiling schema and the metatile schema used in OSM
is very much hard-baked into Tirex.
Jochen
--
Jochen
the node
is deleted. But what happened before? Does the visible="false" on the first
version mean it was deleted before it was re-created as version 2? For a
deleted node, does the timestamp refer to the creation or the deletion?
Jochen
--
Jochen Topf joc...@remote.org http:
/implement new features for Taginfo
* Interface with similar systems such as Tagwatch, Tagstat, and OSMdoc
More information: http://wiki.openstreetmap.org/wiki/Taginfo/Workshop2011
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
regular expression") and I am 99% sure you will get the answer.
> >
> > cheers,
> > Martin
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
timeout handling
are missing. But its good enough to play around with. You'll find the code
at http://svn.openstreetmap.org/applications/utils/tirex/tileserver . Give
it a try!
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-3
tation: http://dev.omniscale.net/imposm.parser/
> Source code: https://bitbucket.org/olt/imposm.parser/src
>
> As the name already suggests, imposm.parser is only a sub-package of a larger
> project: Imposm. It is an importer for OSM data that we are going to release
> in a couple of weeks.
I
ystem is to slow.
I ahven't looked at your logs, but if this happens you should get a message
in your log about the timeout.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
ould be done and whether it would make sense.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Fri, Jan 07, 2011 at 10:25:42PM +, Andrew Ayre wrote:
> Jochen Topf wrote:
> >Osmium is a C++ framework for handling OSM data read from XML or PBF files.
> >The framework itself doesn't do much by itself, it just parses the data and
> >gives you callbacks for
e its statistics.
More about Osmium is at http://blog.jochentopf.com/2011-01-05-osmium.html .
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetma
tat on
http://wiki.openstreetmap.org/wiki/Tirex/Commands and read the man pages.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Tue, Dec 21, 2010 at 11:41:05AM -0600, Scott Crosby wrote:
> On Tue, Dec 21, 2010 at 10:28 AM, Jochen Topf wrote:
> > On Tue, Dec 21, 2010 at 10:08:41AM -0600, Scott Crosby wrote:
> >> On Mon, Dec 20, 2010 at 6:01 PM, Scott Crosby wrote:
> >> > Yes. That is an
Maybe "OSMMeta" or "OSMMetaData" or so?
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
e
statistics for Taginfo (http://taginfo.openstreetmap.de) runs in about 2.5
hours for the whole planet, thats less than half the time it needed when
it was using the XML file format. PBF rocks!
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org
Hi!
Is the HeaderBlock in PBF supposed to be optional? Osmosis only generates it if
there is tag in the XML file. But thats not always the case.
I would expect the HeaderBlock to be required because it contains important
meta information.
Jochen
--
Jochen Topf joc...@remote.org http
is that we'd actually save less than 1%. Thats
not really worth any effort.
And removing tags actually grows the database because there is now a new
version to keep track of. So its even less worth. :-)
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
Hi!
There is a "lite" version of Google´s protobuf library that is considerably
smaller than the full version. Anybody tried this for the OSM PBF format?
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
_
ill be flexible.
I think its probably best we'll let this rest for the moment. We should give
the PBF format some time to be implemented in more places and see where all
the problems are and what ideas we have for improvements. Than later when
we have more practical experience with the f
On Tue, Nov 30, 2010 at 05:07:26PM -0600, Scott Crosby wrote:
> On Tue, Nov 30, 2010 at 2:26 PM, Jochen Topf wrote:
> > 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
> &g
mechanism? If not, its
not a big deal, but we can note it down as possible extension in case we'll do
a new version of the format someday.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing lis
On Tue, Nov 30, 2010 at 10:30:46AM -0600, Scott Crosby wrote:
> On Tue, Nov 30, 2010 at 3:28 AM, Jochen Topf wrote:
> > The PBF_Format wiki page states: "The length of a Blob *should* be less
> > than 16
> > megabytes and *must* be less than 32 megabytes." But fort
On Tue, Nov 30, 2010 at 10:53:16AM -0600, Scott Crosby wrote:
> On Tue, Nov 30, 2010 at 2:21 AM, 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
>
hats
actually useful. But I do mind spending time on code that isn't.
So lets get back to the subject: Is anybody writing PBF files with anything but
zlib compression? Do we need more compression types? If yes, would that be an
option to the writer program or is the writer
take up more than 32 megabytes? Thats 4k
per entity, which could be reached with large relations. Well, we need quite
a few of those large relations, but its good to know where the limits of the
format are and they should be clearly documented.
Jochen
--
Jochen Topf joc...@remote.org http://w
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
d the Translatewiki web pages high and low and couldn't find anything
about that. :-(
Jochen
On Thu, Nov 11, 2010 at 11:11:58AM +0100, Mike Dupont wrote:
> Siebrand and Gerard can advise you on this.
> mike
>
> On Thu, Nov 11, 2010 at 10:05 AM, Jochen Topf wrote:
>
> >
into Translatewiki every time you change the source and re-import them
after translation? Or does it somehow track the git repository of so?
Would it make sense to add Taginfo as a subproject to the OSM project on
Translatewiki?
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/j
iki page and just add a link to the
changeset or something like it?
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
, 2010 at 02:48:12PM +0200, Frank Broniewski wrote:
> Date: Thu, 28 Oct 2010 14:48:12 +0200
> From: Frank Broniewski
> To: Jochen Topf
> CC: dev@openstreetmap.org
> Subject: Re: [OSM-dev] Relation member_roles from Osmosis import
>
> Hello Jochen,
>
> thanks for your answ
stop_%n"
> 207675;"forward_stop_%n"
>
> I think that numbering the member_role is not the intended way ;-)
Thats a left-over from the time when relation members were not ordered.
Jochen
--
Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Tue, Oct 19, 2010 at 11:52:09AM +0100, Andy Allan wrote:
> On Tue, Oct 19, 2010 at 10:25 AM, Jochen Topf wrote:
> > On Tue, Oct 19, 2010 at 10:06:15AM +0100, Tom Hughes wrote:
> >> On 16/10/10 19:44, Jochen Topf wrote:
> >>
> >>> I am currently fight
On Tue, Oct 19, 2010 at 10:06:15AM +0100, Tom Hughes wrote:
> On 16/10/10 19:44, Jochen Topf wrote:
>
>> I am currently fighting some issues where tags with strange characters in
>> them
>> need to be represented in a URL for Taginfo. Lots of other websites probably
>
On Sun, Oct 17, 2010 at 04:57:33PM -0400, Anthony wrote:
> On Sat, Oct 16, 2010 at 2:44 PM, Jochen Topf wrote:
> > Technically this would mean changing the API to check
> > for those characters, removing any that are already in the database (can be
> > done with normal manua
On Sun, Oct 17, 2010 at 09:48:31AM +0200, Ulf Lamping wrote:
> Am 16.10.2010 20:44, schrieb Jochen Topf:
>> Hi!
>>
>> I am currently fighting some issues where tags with strange characters in
>> them
>> need to be represented in a URL for Taginfo. Lots of oth
. Thats different from
the issue
I have been talking about where there are real problems with some characters.
Jochen
>
> Am 16.10.10 20:44, schrieb Jochen Topf:
>> Hi!
>>
>> I am currently fighting some issues where tags with strange characters in
>> them
>>
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags>,
I think thats a misguided use of tag keys probably invented by people who have
never actually tried to write code that tries to interpret OSM tags.
Jochen
--
Jochen Topf joc...@re
201 - 300 of 391 matches
Mail list logo
