Chris Browet wrote:
We all have the same problem: the XML OSM format is not efficient for
mobile devices.
For the time being, we all develop our own solution to transform the XML
in whatever binary format suitable for a mobile application, often
forcing the user to use a specific desktop
On Fri, 8 Aug 2008, Jan Peter Stotz wrote:
May be WAP WAP Binary XML (WBXML) encoding [1] would be a possible
solution? It significantly reduces the size of data to be transfered
while keeping the compatibility to the current data format. The
transportation could be still HTTP or a different
On Fri, 08 Aug 2008 10:17:58 +0200, Jan Peter Stotz [EMAIL PROTECTED] wrote:
Chris Browet wrote:
We all have the same problem: the XML OSM format is not efficient for
mobile devices.
For the time being, we all develop our own solution to transform the XML
in whatever binary format suitable
A binary XML format would be better to parse for an XML processor. But OSM
data is pretty structured. The point is that for line transfers a pretty
efficient format can be choosen that is totally unparsible by embedded
devices.
The actual transfer is pretty much irrelevant here. The goal
On Fri, 8 Aug 2008 10:34:54 +0200 (CEST), Stefan de Konink [EMAIL PROTECTED]
wrote:
A binary XML format would be better to parse for an XML processor. But OSM
data is pretty structured. The point is that for line transfers a pretty
efficient format can be choosen that is totally unparsible
On Fri, 8 Aug 2008, Chris Browet wrote:
As for myself, I prefer to keep all information because I'm not focused on
routing as others. But I suppose compromise will have to be made.
Invent the following format. mmap your program structures to a file, sync
and save it. Distribute.
It will be
May be WAP WAP Binary XML (WBXML) encoding [1] would be a possible
solution? It significantly reduces the size of data to be transfered
while keeping the compatibility to the current data format. The
transportation could be still HTTP or a different binary protocol with a
higher
don't forget looking at the gosmore [1] data format [2]
it does routing and rendering
[1] http://wiki.openstreetmap.org/index.php/Gosmore
[2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00112.html
___
dev mailing list
dev@openstreetmap.org
Dear mobile developers,
We all have the same problem: the XML OSM format is not efficient for mobile
devices.
For the time being, we all develop our own solution to transform the XML in
whatever binary format suitable for a mobile application, often forcing the
user to use a specific desktop
Hello Chris,
not only for mobile devices but for Laptops too
I'd really apreciate a binary-format.
Do you intend to save all the data OSM has
or only support a subset required for routing
and map-rendering?
Do you think about floating-point or fixed-point
coordinates?
We could start by
indeed, every application has other requirements
- editors, wants all data, read/write
- rendering, wants (very) limited datasets, readonly
- routing, remote or local ?
i like the discussion
Rob
2008/8/7 Chris Browet [EMAIL PROTECTED]:
Dear mobile developers,
We all have the same
Do you intend to save all the data OSM has
or only support a subset required for routing
and map-rendering?
The idea is to have a binary format specification.
The actual organization of the files will be up to the application.
Do you think about floating-point or fixed-point
On Thu, 7 Aug 2008 11:03:05 +0200, Chris Browet [EMAIL PROTECTED] wrote:
Do you intend to save all the data OSM has
or only support a subset required for routing
and map-rendering?
The idea is to have a binary format specification.
The actual organization of the files will be up to
2008/8/7 Shaun McDonald [EMAIL PROTECTED]
Chris Browet wrote:
Do you think about floating-point or fixed-point
coordinates?
This is one of the things to discuss. For mobile applications, fixed-point
is the most efficient but we have to balance this with the loss of
precision.
Chris Browet wrote:
2008/8/7 Shaun McDonald [EMAIL PROTECTED]
Chris Browet wrote:
Do you think about floating-point or fixed-point
coordinates?
This is one of the things to discuss. For mobile applications, fixed-point
is the most efficient but we have to balance this with the
!
Date: Thu, 7 Aug 2008 10:47:55 +0100
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: dev@openstreetmap.org
Subject: Re: [OSM-dev] Call to mobile developers: OSM binary file format
Chris Browet wrote:
Do you think about floating-point or fixed-point
coordinates
Thank you Pol.
It sounds great,
can someone start organizing what we have on a wiki-page?
I guess we should get a concensus on the purpose of the applications
what are to be offered usage of this file-format first.
Porposal:
I propose it to be ment for routing and navigation.
Motivation:
On Thu, Aug 7, 2008 at 8:32 AM, Chris Browet [EMAIL PROTECTED] wrote:
We all have the same problem: the XML OSM format is not efficient for mobile
devices.
For the time being, we all develop our own solution to transform the XML in
whatever binary format suitable for a mobile application,
On Thu, 7 Aug 2008 13:07:11 +, Ævar Arnfjörð Bjarmason [EMAIL
PROTECTED] wrote:
There's a reason people use XML, it's an interchange format but binary
formats aren't, they're meant for specific architectures or purposes.
Which is not to say a discussion like this one isn't useful,
Hi Everyone,
my company developed a navigation software , We're actualy using a
professional vendor map , in this 4 years of develop we change our
binary format every 3/4 month , because the problem is that the embedded
device , normaly ARM 10 based have a small resurce , small ram memory ,
Hi Marcus,
normaly the company as Teleatlas or Navtech sell their data in some
public format as shape or GDF , then the data is organized in different
way , but is not binary data. Is not possible to share this kind of
technical information because We sign a NDA. But if you have some
question
Good idea :)
I am always tempted to do my own binary vector map format after suffering the
madness by Garmin. However the wonderfull world of raster maps keeps me from
doing it.
Anyway, I would suggest you have a deep look into the Garmin binary
sepcification. Some things are good, some are
Hi,
Chris Browet wrote:
Well, no, this is not different. This is exactly the ballpark we want
to play in.
Are you saying that you want to remove the distinction between the
transport format and the format actually used on the device? This would
mean that you would, for example, expect the
Graham Asher, developer of CartoType (presented at SOTM 2008)
www.cartotype.com
, has asked me to forward this to the list.
===
The format used by CartoType is publicly available under an open
license. See http://www.cartotype.com/cartotype_map_data_format_type_1.html
. The format
2008/8/8 Frederik Ramm [EMAIL PROTECTED]
Are you saying that you want to remove the distinction between the
transport format and the format actually used on the device? This would mean
that you would, for example, expect the API to provide index lookup tables
and other stuff that is derived
25 matches
Mail list logo
