iKatastr2 update je na App Store ! Diky všem, kteří jej používají a podporují tento projekt. Těší mě, že se aplikace hojně používá – a to byl také hlavní důvod aktualizace aplikace.
Tento update je udržovací – obsahuje rekompilaci na nejnovější iOS a zároveň stále podporuje iOS od verze 6. Byla aktualizovaná knihovna Google Maps SDK a opraveny drobné chybky. Můžete zde napsat své názory, komentáře a ještě lépe přímo na App Store iKatastr2 ocenit – to je jediná měna, kterou můžete za aplikaci, která je zdarma “zaplatit” – a věřte, že každý pozitivní ohlas dodává vývojáři palivo, smysl a chuť v tom pokračovat a třeba i něčím novým překvapit :)
This chart shows real usage (sessions) of iKatastr app over 5 years of running as app on iOS, Android and on PC as web page in CZ. Tiny Windows Store app and Windows Phone app usage couldn’t be rendered at all.
or no ? … how to explain this picture ? iKatastr was indeed attempt to introduce new term for accessing cadastral data in Czech Republic, and it launched on iOS, Android and web 5 years ago, no public advertising, no ads at all… Anyway I like this picture, and it is kind of surprising that GISCloud nor mangomap doesn’t enjoy the same level of trending according to Google Trends. I think reality is different
..let’s look on another measure – site visits using simlarweb.com
Looks like Google Trends takes into consideration # of visits and is more weighted than media coverage ? Or does the mobile presence of app iKatastr adds so much ‘ads’ to the final chart ?
…před 20 lety jsem tuto knihu našel na stole v jednom starém, opuštěném domě v Brně, dodnes se k ní vracím jako k pokladu…
Breviář PŮJDE TO ! ING J. SOLAR, Praha 1938, 3. vydání
First time 100K visits over month period. 20M clicks & reaching 3M sessions overall.
I have got great, absolutely amazing joy today from my own open source experiment. In 2014, nearly 2 years ago, I have published on GitHub (gist) L.CanvasOverlay a small class to handle generic drawing on top of Leaflet, I was thinking let’s try to contribute back to the open source with this little snippet – I thought would be useful so I have added little description. Original blog post here: https://blog.sumbera.com/2014/04/20/leaflet-canvas/
After few months later I found it is used on http://windyty.com one of the best 2015 geo-visualization with huge popularity. It is a small part of this great app, but makes me feel so good like I am part of it, I am looking on something where is my small piece, small share…meaning of the effort, sense of publishing and open sourcing.
And today I have got echo it is used also in Marine National Facility here: http://www.cmar.csiro.au/data/underway.test/
This makes me so happy … and just came across this quote : “Revenue is a lagging indicator, usage is a leading indicator,” can’t remember, who just said that ? :)
SVG can be drawn on map in much more faster way than traditional approaches, at least for points. Traditional approach re-position each element to fit into the view of the map, however SVG is “scalable” so we can use it and it performs much more faster for zoom-in/out.
- SVG itself define viewport by its coordinate space, all outside of this viewport is usually clipped, so it is important to keep SVG viewport in-line with the viewport of the map. There are approaches that resizes SVG as you zoom-in (here), and while it works, it has a problems in deep-zooms when you need to move on map (actually you move giant SVG based on the zoom )
- translating LatLon to absolute pixel values (like here used for WebGL) is possible solution, however IE and FF has problems with large numbers for transoform (>1 M), So we need to get SVG elements in view coordinates and translate them.
- Having some track of bounding box of all elements like again used here should be avoided (SVG or its group element knows about extension of the elements it holds)
- So while we keep SVG in the viewport, we need to compensate any shift and zoom by translating <g> (group) of all elements.
- So in leaflet when map moves, SVG is translated back to its original position while <g> is translated forward to reflect the map movement
- We need to keep track of LatLon position of either map center or one of the corner – we use topLeft corner.
- Leaflet doesn’t do precise enlargement and rounds view points because of some CSS troubles on some devices (noted here). We need to patch two translating functions in Leaflet to get this right (so SVG enlargement will be aligned with map)… but I need to look on this again, best would be to not patch Leaflet of course.
most important things happen in moveEnd event:
var bounds = this._map.getBounds(); // -- latLng bounds of map viewport var topLeftLatLng = new L.LatLng(bounds.getNorth(), bounds.getWest()); // -- topLeft corner of the viewport var topLeftLayerPoint = this._map.latLngToLayerPoint(topLeftLatLng); // -- translating to view coord var lastLeftLayerPoint = this._map.latLngToLayerPoint(this._lastTopLeftlatLng); var zoom = this._map.getZoom(); var scaleDelta = this._map.getZoomScale(zoom, this._lastZoom); // -- amount of scale from previous state e.g. 0.5 or 2 var scaleDiff = this.getScaleDiff(zoom); // -- diff of how far we are from initial scale this._lastZoom = zoom; // -- we need to keep track of last zoom var delta = lastLeftLayerPoint.subtract(topLeftLayerPoint); // -- get incremental delta in view coord this._lastTopLeftlatLng = topLeftLatLng; // -- we need to keep track of last top left corner, with this we do not need to track center of enlargement L.DomUtil.setPosition(this._svg, topLeftLayerPoint); // -- reset svg to keep it inside map viewport this._shift._multiplyBy(scaleDelta)._add(delta); // -- compute new relative shift from initial position // -- set group element to compensate for svg translation, and scale</pre> this._g.setAttribute("transform", "translate(" + this._shift.x + "," + this._shift.y + ") scale(" + scaleDiff + ")");
Test page / Gist : http://bl.ocks.org/Sumbera/7e8e57368175a1433791
To better illustrate movement of SVG inside the map, here is a small diagram of basic SVG states: