Tilemill works great, mostly very usable! I managed to get to the part where I am making svg exports of my map made with osm-bright as a starter. That seems to be fine but I cant work out how the resolution I specify for the SVG relates to the zoom levels. I guess it has something to do with the tile size, can someone help me understand this?
Thanks a lot, Joris.
First, for printing, the resolution is 90.7 ppi (some OGC standard or whatever). Some round it down to 90 ppi.
Zoom-to-scale relation is calculated in this table: 1:2132 on z18, 1:4265 on z17 and so on. Also see this page on OSM wiki for formulas.
Related
I'm stuck with a problem of blurry images despite using svg, which lead me to the official OL docs with a solution which I quite don't understand - https://openlayers.org/en/latest/examples/svg-layer.html
I've tried to follow this example, but obviously it doesn't work by just copy-pasting. I would like to know where the formula svgResolution = 360 / width comes from, as it used to calculate the scale and [x,y] transforms of the div. I'm not that familiar with using OL, so any kind of help will be appreciated.
I am using SVGPanZoom to manage the zooming of an SVG image in my hybrid Android (for all intents and purposes the same behavior as in Chrome) app. While zooming works well I have found a strange issue. My original inline SVG element goes like this
<svg id='puzzle' viewBox='0 0 1600 770' preserveAspectRatio='none'
width='100vw' height='85.5vh' fill-rule='evenodd' clip-rule='evenodd'
stroke-linejoin='round' stroke-miterlimit='1.414'
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://
www.w3.org/1999/xlink'>
Initially this SVG element is empty and gets populated programmatically from JavaScript at run time after which I initiate SVGPanZoom as follows
var panZoom = svgPanZoom('#puzzle',
{panEnabled:false,controlIconsEnabled:false,
zoomEnabled:true,dblClickZoomEnabled:true,onZoom:postZoom});
panZoom.refreshRate = 10;
panZoom.zoomScaleSensitivity = 0.02;
The problem I have run into is this - I want my SVG image to fill the available area, 100vw x 85.5vhcompletely to do which I instruct it via the preserveAspectRatio="none"attribute above along with the viewBox="0 0 1600 770" attribute. I have found that this works - so long as I don't use SVGPanZoom. As soon as I initiate panZoom thezoomBox`attribute gets stripped out and I end up with an image that does not quite behave in terms of its default stretching/filling behavior.
SVGPanZoom is widely used so I assume that this behavior is down to me not quite setting it up properly. Dipping into the code I have found SVGPanZoom creates a cacheViewBoxand then proceeds to remove the original zoomBox attribute.
Which is fine if after that zooming works and the original behavior of the application does not change which is not what I find. What am I doing wrong here?
I've also run into this issue recently. From my research, this is just how the library works. I chose to live with this limitation for now but I found a couple other libraries that may work the way you intend (I haven't tried them yet):
jquery.panzoom is a jquery library that provides this functionality and also has some nice features. I know many people try to avoid jquery but it's pretty small and may do what you want. It handles SVG but I don't know what it does with the viewBox attribute.
react-svg-pan-zoom is a react component which may be useful if you are working in react.
I've also tried the PanZoom library but this also suffers the same viewBox limitation.
A note for anyone running into this thread. In the end I abandoned SVGPanZoom and decided to eschew the route of using any pan/zoom library at all. At the same time I decided to completely stop using the SVG viewBox and handle all zooming/panning entirely on my own through SVG transforms. The core steps involved
Wrap the entire SVG contents in a group to make it easier to manage the transform. I use the id attribute gOuter for this group
Set an initial scale for the SVG to occupy the desired client rectangle. In my case I had an original viewBox of 0 0 1600 770 intended to occupy 100% of screen width and 85% of screen height. So my scaling was scaleX = 1600/window.innerWidth and scaleY = 770/)0.85*window.innerHeight).
Apply this initial transform to the wrapping outer group, gOuter.setAttribute('transform','0 0 scaleX,scaleY)
Now in order to zoom to a an object whose virtual top left hand coordinates in the original viewBox were Ox,Oy you would use the transform
gOuter.setAttribute('transform',
scale(scaleX,scaleY) translate(-Ox,-Oy) scale(2*scaleX,2*scaleY) translate(Ox,Oy))
to zoom in by a factor of x 2. The important things to understand here
In SVG transformations are applied right to left.
Here we are translating the zoom point to the top l.h.s. scaling and then translating it back to its original location.
The problem is that we also need to allow for the original level of zoom through the initial scaling so we tag that on as one last transform
This leaves you in complete control of the zooming process and as a fringe benefit the operation becomes considerably more smooth than when using a pan/zoom library.
I am having issues with inconsistent SVG rendering of what seems to be a basic file between browsers. I need to find a way to make this SVG cross-browser, but can't seem to pinpoint the problem. Firefox 23 and Inkscape issues go away if the stop-color statements for the gradients are moved from the CSS to style = style="stop-color:#XXXXXX". Sadly, this is not an option because of the way this file will be used. This file validates on the W3C validator, and seems to only use simple features, but rendering is inconsistent. What is wrong?
I am not allowed to post images yet, so here is a link to an image showing the problem:
http://www.flickr.com/photos/95652985#N07/9754841655/lightbox/
SVG Source is here:
https://dl.dropboxusercontent.com/u/11366066/fire.svg
Thanks for help with this baffling problem!
I think your coordinates x1,y1, etc (for instance
<linearGradient id="id1" gradientUnits="userSpaceOnUse" xlink:href="#id0"
x1="32093.5" y1="4749.35" x2="37189.8" y2="4749.35">
)
could exceed the user space bounding box, thus got wrapped in Chrome, and clipped in Firefox, etc (also my Ubuntu SVG viewer get the same results as Firefox).
A bit of philosophy: SVG, like HTML, is required to be tolerant in rendering, then is common to have different behaviours where the 'simpler' specification is extendend (actually SVG is far from simple)
Edit: my SVG viewer reports as dimensions: 4252 x 2835 pixels 74,2 kB 34 %. Even if we multiply 4252 * 3 we are far below the x1,x2 values....
I've got a problem with my MKAnnotationViews when MKUserTrackingModeFollowWithHeading is enabled on the MKMapView.
I positioned my images using the centerOffset property of the MKAnnotationView. Specifying the coordinates of the pin's tip relative to the coordinate system at the center of the image is somewhat counter-intutive, but I came up with the following formula:
annotationView.centerOffset = CGPointMake(imageWidth/2.0 - tipXCoordinate, imageHeight/2.0 - tipYCordinate);
This works fine for zooming the map in and out. The tips of the pins keep their relative position on the map.
However, when I enable MKUserTrackingModeFollowWithHeading, it won't work anymore. The Pins rotate around the center of the image, instead of the tip. So when the map rotates, the tips do no point to the locations they are supposed to annotate.
I've played around a bit with the frameand centerproperties of the MKAnnotationView, but I feel, they are having no effect on the alignement of the pins whatsoever.
Interestingly, the MKPinAnnotationView does not seem to use centerOffset at all, but a shifted frame instead. However, I was unable to reproduce this. Changing the frame of my custom view did not move it at all.
Thanks for any insights you can provide :-)
Solution:
Don't use centerOffset! Use annotationView.layer.anchorPoint instead. The coordinate system of achor point is much nicer, too. Coordinates range from 0.0 (top/left) to 1.0 (bottom/right) of the image rectangle:
annotationView.layer.anchorPoint = CGPointMake(tipXCoordinate/imageWidth, tipYCordinate/imageHeight);
A friend asks me to let you know that you should "try this for instance":
self.layer.anchorPoint = CGPointMake (0.5f, 1.0f);
I am new to opengl and visual c++. I have done a sample application which rotates 3D shapes in opengl. I want to allow the user to rotate and zoom the object. Please give me an example of how to do this.
I have tried NeHe tutorial: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=48
I can't understand the class structure in the example. Is there anysimple way to achieve this?
I have found a library as well: http://www.nigels.com/glt/gltzpr/
But still can't figure out how to do this.
Please help me.
Zooming is usually done through gluLookAt. The third parameter is the view distance.
Here is some basic example running this :
http://graphics.stanford.edu/courses/cs248-01/OpenGLHelpSession/code_example.html
Look in display() to see how the viewing distance is used and in MouseMotion() to see how the value is modified and the painting updated.