On 12/17/14 10:00 AM, Matěj Cepl wrote:
On 17/12/14 03:07, Adrian Custer wrote:
...
'curating' data is a common term for checking data, fixing errors,
finding mismatches, and generally not using a raw data dump but doing
some work with the data before use. Reports generally from people
using OSM data is that the data need work before use.
This is IMHO very very much dependent on the location.
...
OSM provides maps
of the similar quality to Google, and everything else (namely Nokia
Maps) are distant distant second.
You may be mixing two different ideas: overall data quality versus
specific data errors. Curating involves making sure that small errors
don't ruin the rest of the data; it is not a data gathering effort at
all nor a comment on the overall data quality of a data set. Sometimes a
single small street is connected in a strange way to a major autoroute
or even to a train track or something similar and that tiny error leads
to huge visual or algorithmic problems. Curating involves inspecting the
data and correcting these tiny errors that have big impacts. This ends
up being critical when doing routing, or address matching, or other
advanced mapping stuff and sometimes even in simply rendering the data.
The OSM terms: http://wiki.openstreetmap.org/wiki/Tile_Usage_Policy
Oh, tiles ... tiles are not data I meant,
Right. There are two different things going on. First is a simple map
widget that shows tiles. Second is getting a blob of actual data and
being able to render or to do analysis on that data. The first is vastly
easier than the second. However, both require a web service willing to
furnish FirefoxOS devices in general with either tiles or prepared
data---a non-trivial investment.
and yes if OSM mapping app
would be part of FxOS, then it is probably (and rightfully, IMHO)
expected from Mozilla to have its own servers. But that should be
covered IMHO just by providing hardware and administration of
FLOSS software on it, so not much development needs to be involved,
hopefully. And also this starts to be consideration once the app is
widely deployed. I don’t think anybody limits
https://marketplace.firefox.com/app/osm-viewer or
https://marketplace.firefox.com/app/lantea-maps
Well actually this is why things like Mapbox and providers of data and
javascript widgets other than Google exist. Without prior agreement,
HTML widgets, and especially web apps, are not supposed to hit the OSM
tile servers. Other providers allow this if you sign up and register and
... but their code is generally not free software and the limits on use
sometimes conflict with something users want to do, like store tiles for
offline use.
As for the apps you mention, lantea-maps for some reason is using the
OSM tile servers directly, which may or may not be legal. I suspect
osm-viewer is doing the same, though have not seen its source code. Both
are probably under the radar enough not to matter.
As I said, I don’t think there is anything wrong in saying that, but
your statement read to me like “OSM mapping cannot be done, because we
don’t have a way how to share data with other apps”. If I misunderstood
you, then I am sorry for confusion.
Cool. Now we are getting somewhere. This is *not* what I was saying at all.
Rather, I am saying something along the lines of:
For FirefoxOS to rock, it needs a good mapping app provided by
default, one that works offline as well as online.
In order for such an app to happen, some work will be required to
curate data, set up servers (first tiles, then data), and develop
code. (The gathering data step can, thankfully, be skipped since OSM
is a suitable source of data.) In a general solution aiming to make
FirefoxOS rock, if Mozilla were to take on this role, it could ensure
a free of charge and free of registration barriers access to map data
for all apps on the device, along with free software code able to
evolve and grow.
A modular approach to that work would think in terms of two functions
on the FirefoxOS device: one part to manage data (select a region,
download data from the service, store the relevant data, serve the
data either raw or rendered to the data using code, and erase
data no longer needed), another part to use the data for some
'mapping' purpose, presumably, in a first instance, for a map viewer
and geolocator. These can be part of the same 'app' but are two very
different sets of actions.
A modular approach to the work, would split these two
functions. This naturally leads to the ability to offer map
data as an inherent functionality available to all other web apps on
the device. This allows third-parties to build on the work
and develop alternative apps which gives mapping room to grow. That
is, a well built, modular mapping app can transcend being an app to
being a map engine for the platform. One issue to this approach is
that it does require a different IPC mechanism, a mechanism along the
lines of part of the discussion taking place in the thread:
Cross origin communication and the navigator.connect API
wherein the map manager app could offer an API to all other apps on
the device.
Unfortunately, this work involving data management, setting up
services, developing code, extending the IPC system, and building user
apps, is unlikely to happen. The need to monetize the
work conflicts with the goal to having a fully open, freely licensed
mapping service, code, and application. Mozilla, which could take on
this work, has other priorities. So, despite the usefulness to users
of having a mapping app and having a mapping service available to any
other app that wants it, I suspect mapping is not going to happen on
FirefoxOS in this way.
So yeah, that's a long and complex argument. Just to understand the
different components takes a careful read and probably requires
understanding the web mapping landscape to some extent. Then, if you get
into the nitty gritty of it, the argument can get even more complex,
especially if you want to look for opportunities to tie into and
leverage international mapping standards to make the whole thing robust
in the longer term.
Anyhow, that's my take on the mapping situation on FirefoxOS. I got far
enough along to make a stumbling app prototype which is how I ran into
all the issues I now see.
cheers,
~adrian
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
