-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map views that are device and web browser independent #294
Comments
Would saving the view to user account work? Saving the view from the camera icon/"my data" stores the map center coordinates. Printing takes the center coordinates and "paper size" to create the PDF so it should give same results if you restore saved view from My data and click print without moving/dragging the map in between. |
The problem with the print functionality are at least that
|
Not sure what could be done about quality of PNG printouts. The print functionality should already fetch the same raster images from WMS/WMTS services as the frontend does so the input for the process should be identical. Also, as PNG uses lossless compression there is no loss of quality from encoding the image as png. Some example images would be helpful in debugging the issue. Here's a png I captured with browsers built-in Save image... (and cropped it from 1750x961 to 679x961 with offset of x=535) And here's a png saved from https://kartat.tampere.fi/oskari/action?action_route=GetPrint&format=image/png&pageSize=A4&resolution=8&srs=EPSG:3067&coord=327304.66825_6822494.74555&mapLayers=1918%20100%20raster&scaledWidth=200 -- I can't really spot the difference |
Some example images highlighting the issue would be useful for identifying the underlying problem and also get us closer to the possible fix |
In my mind the requirement of getting specific size needs to be solved using the server-side printing. We don't really have control how client-software on user device behaves if we would make an element larger than what is within limits of the user device. |
There's a slight issue with the wording here. Currently with Tampere Oskari (and all other Oskari installations without customized scale sets configured for printout) the user is not able to select different scale for printing compared to that which the map is viewed with. For example, in Tampere Oskari both the frontend and print service use the same resolution (meters per pixel), and thereby scale, from the set of [2048, 1024, ..., 0.125, 0.0625]. However, the 0.125 meters per pixel doesn't correspond to any well known scale (1:500) etc, but it is not different from the one the user is browsing the map with. However, the viewports (bounding box) between client and the generated pdf/png differ most of the time as the generated pdf/png is targeted towards a known paper size (A4/A3/A2, portrait or landscale) whereas the bounding box in user screen depends on multiple things (for example screen DPI due to hi-dpi device or different operating system, user preferences and zoom settings etc.) |
At least someone at the Tampere comprehensive land use planning unit is about to do testing again on the Tampere Oskari when there are less land use planning work hastes. |
Somewhat related to #258 and #283 there is a need that user is able to save map views that allow saving or/and printing map images from exactly same coordinates with exactly same bounding box independently of the computer, display and web browser the user is using.
This is needed at least when creating pdfs of the comprehensive land use plan maps of various themes of the same location utilizing the the theme maps that are in the Oskari. For example, Tampere has among others the following thematic comprehensive land use plan maps in Tampere Oskari:
These oskari maps have pdf counterparts (the links below include also other maps and data):
In Tampere we are going to create the pdf maps serveral times during current city council period (2021-2025) quite similar to above and the following city council periods at least in the near future are probably not any different. Therefore this enhancement would be useful for now occasionally in Tampere.
The text was updated successfully, but these errors were encountered: