I am about to start a web application with the main purpose of displaying a mapbox map, toggle layers and display data based on interactions with the map.
I'm wondering should I be using mapboxgl.js AND leaflet.js, mapboxgl.js OR leaflet.js. Everyone keeps saying leaflet is amazing but wondering if mapboxgl gives you the same functionality and performance? I keep reading conflicting things on the internet
Would really appreciate the help
A few words to clarify the difference:
mapboxgl uses browsers' WebGL technology, therefore it requires a modern enough browser, and uses more client computing power. The advantage is that it can natively handle vector tiles and render them any way you like (rotation, tilt, perspective like for a GPS navigation device, custom style, etc.)
Leaflet uses plain DOM manipulation, and is designed to (theoretically) support old browsers like IE8. It is very efficient for such old browsers, and also mobile-friendly due to this lightweight computing footprint. The advantage is that it enables you including a basic map without too much overhead. Most basic usages can be covered with Leaflet, possibly with some plugins. The drawback is that it mainly supports raster tiles, so they must be rendered server-side (mapbox provides such service).
Related
We need to build an image processing application for smartphones (mainly for iPhone). The operations consist of:
image filtering
composite geometrical transformation
region growing
Also, the user is required to specify (touch) some parts of the image. Those parts would serve as inputs for the app. Example: eyes and lip in a face.
We have built a desktop version of this app. The processing part is quite heavy and we extensively used BufferedImage class.
Should we use CodeNameOne for building this app? If not then what alternatives do you suggest?
Please consider the following factors:
Performance
Ease of writing the code (for image processing)
I gave an answer for this in our discussion forum but I think its a worthwhile question for a duplicate post:
Generally for most platforms you should be fine in terms of performance except for iOS & arguably Windows Phone.
Codename One is optimized for common use cases, since iOS doesn't allow for JIT's it can never be as fast as Java on the desktop since its really hard to do some optimizations e.g. array bound check elimination. So every access to an array will contain a branch check which can be pretty expensive for image processing.
Add to that the fact that we don't have any image processing API's other than basic ARGB and you can get the "picture", it just won't be efficient or easy.
The problem is that this is a very specific field, I highly doubt you will find any solution that will help you with this sort of code. So your only approach AFAIK is to build native code to do the actual image processing heavy lifting.
You can do this with Codename One by using the NativeInterface API which allows you to invoke critical code in native code and use cn1lib's to wrap them as libraries. You would then be able to get native performance for that portion of the code but this would only make sense for critical sections in the code. If you write a lot of native code the benefits of Codename One start to dissipate and you might as well go to native.
For my Windows Phone Mango app, I want to make overlay a heatmap on Bing Maps, and a tile overlay seems the best way to do it. I've been having trouble finding any good documentation or code samples to work from. It seems like most people are pointing the tile source to a web service. I'd rather render the heatmap on the phone itself - is that possible?
One of the main reasons to use tilelayers to represent data on a map is that the computation and rendering involved in creating the layer is performed in advance, generally as a one-off or infrequent task. Then, at runtime, the only work the client needs to do is to retrieve the pre-rendered tile images from the server and display them straight on the map, which is a simple, low-resource activity.
Rendering tiles can be a resource-intensive task, both in terms of processing and memory usage - for example, I can only render about 3 tiles per second on a quadcore desktop machine with 8Gb RAM. Even if it's technically possible to create the tiles dynamically on a handheld device, the performance is almost certainly going to be unacceptable for any user. You've also got the question of how you're going to store the data from which the layer is created. Since you're talking about plotting a heatmap, I'm guessing you have a reasonably large dataset of points - did you envisage these stored locally on the device, or retrieved over the network? (either will create different problems).
Basically, while it may be theoretically possible to create tile layers dynamically on the client, doing so would negate almost any benefit of using tilelayers in the first place, which is why you probably won't find any code samples explaining how to do so. Perhaps you could explain your comment why you'd rather create the heatmap on the phone?
It's pretty easy to create a server-side tile renderer using .NET or PHP that renders and server tile images to a Bing Maps client, or you can use an existing map rendering library such as mapnik.org or geoserver.org.
I have designed and developed couple of navigation apps using google API and osmdroid API for android powered devices. Now I am looking to create an Indoor navigation system using osmdroid API. But, in order to do so I need to create tiles similar to regular map tiles from an simple PNG file with naming convention similar to OpenStreetMap.
Please suggest me how to do this?
Cheers,
Susheel
You could design your indoor map using JOSM. Save it to a .osm file. Don't upload the data to OpenStreetMap unless it is a appropriate to do so (OpenStreetMap has some basic some indoor features, e.g. a highway=footway running through a shopping mall, but generally a lot of very detailed indoor stuff will be inappropriate for OSM) But...
With a .osm file you could then use one of the OpenStreetMap rendering tools to create a raster map, and chop it into tiles. For quick satisfaction I'd recommend Maperative, although I'm not sure how easy the last tile chopping step is. I've never done this with Maperative. Mapnik has a nice generate_tiles.py output, which will give you the tileset you want, but it's a bit tricky to set up in the first place.
Actually the last step is the main thing you're asking about. You can chop up any image into tiles. It may or may not be important to you that the tiles are geo-positioned in some meaningful way. For an old project I did a quick fudge solution using google tile cutter script, which is actually a wrapper around GDAL tools.
Have a look at the gdal library, and in particular gdal2tiles. This is a library designed to create maps from raster images, and serves exactly your purpose.
You can decide on a projection and what the bounds of your source image(s) are. The library allows you to reproject your image to the correct coordinate space.
It can also generate tiles at various zoom levels using gdal2tiles, either with or without reprojection.
Now you can check indoor rendering by drag and dropping OSM geojson data into https://app.openindoor.io web page.
This question has been asked in various guises. However. this is a slightly different take on things. By web application, I mean an ultra lightweight frontend - ideally an HTML page with form and regular buttons, with as little dependence on heavyweight JS libraries like jQuery as possible.
The goal is simple. I want to write a simple forms based application for use accross various mobile devices. I thought going the HTML route would be the simpler route (since browsers get around the whole cross platform issue) but even the browser approach seems problematic because of differing screen sizes on mobiles.
I have two questions:
For a simple form based application like I have in mind (possible 3-4 screens in total), I think the browser based approach gives more bang for my buck - am I missing a trick?
Are there any resources that someone can point me to for:
a useful reference for minimum (i.e. lowest common denominator) window size (I forget the technical term for the visible part of a page)
perhaps an example that will show a simple HTML page that will render correctly accross multiple devices?
The HTML5 mobile boilerplate will probably answer a lot of the questions about how to best get things to work across browsers:
http://html5boilerplate.com/mobile/
They have example markup and template implementations for things like browser/device specific CSS hacks, getting a custom launcher icon across different device styles, and implementing offline digest.
You really need to answer two questions before you pick a platform. First, what mobile devices and/or device capabilities are your lowest common denominator? There are lots of variable capabilities between most of those platforms -- screen size, input method, platform speed and mobile platform to name a few. Second, what is your connection requirement? Completely different issue building something targeting spotty or no connectivity versus a fully connected app.
Then you can start thinking about what tool(s) might get you there. In general, a very, very simple HTML site will look okish on most platforms you list. I wouldn't roll with HTML5 functionality because you've got serious limitations there. And HTML/web apps are kind of moot if you need things to work with limited connectivity.
iOS (webkit), Android (webkit) and BB OS6 (webkit-ish), are fairly easy to develop for.
Windows 7 should be, but who knows? They aren't promising HTML5 support until end of year.
BB OS5 browser sucks if you hope to be doing DOM manipulation or fancy JS event listeners. It's really buggy.
Nokia...it's a crap shoot. Granted, they have about one year left before they ditch their OS anyways.
Screen sizes are an issue, as is the fact you can change the orientation. But that can be gotten around with some careful planning.
HTML5/CSS/JS is definitely the way forward for making cross-platform apps as easy as possible...be it in the browser, or as a compiled app.
I am currently working on a navigation based app which uses third party maps. I use a lot of tiling. Though the maps are of very high resolution, I estimate an average of 6 tiles each of 256 * 256 pixels loaded . I might refresh the tiles like once in five minutes. I am currently using UIScrollview + tiles...
Should I really switch to Open GL ? I am hestitant to use Open GL because all the zoom functions and scrolling have to be hard coded in case of Open Gl.
Could some one please suggest the performance difference I would have?
Thanks
I don't have any Apple development experience, but I think this falls under the more general practice of avoiding premature optimization. I'd say go ahead and implement it as simply and naturally as possible. If you (or the app store overlords) find that it has performance issues, then it might be worth the extra investment of time.
Be sure to structure your code with modularity in mind. Develop your own simple interface for displaying the GUI from the core program logic. Then, once you decide to switch, you should be able to develop an OpenGL replacement to drop in, using the same interface.