Re: [b2g] FirefoxOS Mapping [was: Dogfooding Results]
On 17/12/14 14:52, Adrian Custer wrote: > 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. Do you know much effort goes exactly in this kind of QA around OSM? Czech community just starts with http://osmose.openstreetmap.fr/cs/map/ but it is by far not the only system of discovering exactly this kind of bugs. A lot of fun is with http://maproulette.org/, completely addictive if you are into such stuff. And yes, my conclusions about quality of here.com v. OSM v. Google Maps are based on many attempts to use both for routing. Quality of routing varies for ALL maps, but quite strongly OSM and Google are almost always way above Nokia Maps which generates sometimes very wild routes (500+ km route from Prague to Krakow, which suddenly goes in the middle through a unpaved cart track is probably the top achievement). Yes, they have some traffic information which is useful (contrary to OSM). And it is not only in Czech republic ... in rural Italy, OSM is consistently best for routing (way ahead even of Google). Nokia Maps have most of the three most outdated maps (missing cross-roads, road extenstions, etc.). > 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 the third is actual vector data covered by ODbL. Which is what I meant. > 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. That was my point. There is an opportunity to develop your map for free, and only when it becomes popular (if it becomes popular) you have negotiate with OSM some resolution of your situation. > 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. Actually this doesn't *require* modular design of Firefox OS mapping software (of course, it would be helpful if some mapping source module would be part of the Firefox OS system itself). It could be a tremendous help to the situation of mapping applications, if Mozilla just provided a tile servers etc. for free for anybody developing and deploying FxOS-compatible mapping applications. Is this Mozilla-provided data source what you had on mind? > 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. You actually start to persuade me. My Flame fell on the floor other day and the glass broke. So, I have been thinking about buying new phone. After reading your messages you have mostly persuaded me, that if I want a decent phone (better than your average $25-phone), I have to buy Android in the end, because FxOS will never provide decent service (and yes, decent phone for me includes an equivalent of OSMAnd). It is sad, but you might be right in the end. Perhaps FxOS is really only about “phones for Bangladesh” and even decent HTML5-apps are better served via Fennec on Android. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC <"}}}>< ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] FirefoxOS Mapping [was: Dogfooding Results]
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 mechan
