I need to display in mapstore the italian cadastral wms (EPSG:3857).
I choose to use wms cascading with reprojection function in geoserver from EPSG:6706 to EPSG:3857.
Unfortunately, the results were not what was hoped for, in fact the projection on OSM is displayed in a wrong area
(Eritrea...more or less). Can you tell me what am I wrong?
This is the italian cadastre service (EPSG:6706) that I used for my tests: https://wms.cartografia.agenziaentrate.gov.it/inspire/wms/ows01.php
When I tested this I get the Copyright symbol in the correct place (near Italy) but no data displayed (probably due to a scale denominator issue).
I handled reprojection by leaving it in the native projection and reprojecting on output.
As you can see this handles the axis order switch correctly (6W, 35N)
In layer preview the image is fine in EPSG:6706
But vanishes except for the copyright if I switch the bounding box and ask for EPSG:4326. When I try in QGis I get the same result with both WGS84 and Web Mercator.
Since the WMS server seems to be written in PHP I suspect it may be misbehaving, you may be best asking the provider for the actual data and serving it yourself. Or ask them to switch to GeoServer (it's free).
Update
It is definitely broken - when I load the WMS directly into QGIS I get:
Related
Sorry to bother you with a probably easy question.
We would like to set up an WMS (web map service) that forwards all the requests to three other WMS depending on the scale (zoom intervall).
The aim is to combine 3 background maps (which show the same geografic area in different levels of detail and come in 3 seperate WMS) into one WMS so the users can zoom in and out seamlessly using just that one WMS that the forwards the WMS-requests to the other 3 WMS.
Is that possible? Is there a software can help me to solve my problem?
Thank you in advance!!
The functionality you are looking for is called cascading. It is possible to do this using GeoServer.
The GeoServer manual explains in detail how you can set up a cascaded WMS layer. However, there is not currently any way to apply a scale limit to a cascaded layer unless the source server applies it.
Another project that supports cascading WMS is MapProxy but I'm not sure if it can change sources depending on the scale of the request. It does have the option to limit a request to a min/max scale but it returns a blank image outside those limits.
I'm generating data for training an object detection ANN. I'm currently automatically generating the training data based of rules which i'm implementing (automatically captures the image and creates bounding boxes), however the algorithm for creating the data is imprecise (otherwise i wouldnt need an AI for it)
I am looking for an app or github repo that inputs the Pascal VoC annotation file and image, and allows you to visually modify (add/remove/update) the bounding boxes to clean up the data. Using windows currently.
Cheers
Depending on platform I use:
Linux/win - LabelImg
macOS - RectLabel (unfortunately not open source, but only costs $0.99)
I want to publish the data in the Oracle DBMS.
Since the SRS of the data (which is EPSG:3093) is different from the SRS the client wants (which is EPSG:5179), it must be transformed.
So, I’ve set the layer property on the Edit Layer page as follows:
Native SRS: EPSG:3093 (Tokyo / UTM zone 52N)
Declared SRS: EPSG:5179 (Korea 2000 / Unified CS)
SRS handling: Reproject native to declared
The problem starts now.
When I clicked ‘Compute from data’ for Native Bounding Box, it displays the result coordinates in Declared SRS, no Native SRS.
Is this the correct behavior? Since it is ‘Native Bounding Box’, the values should be in Native SRS.
Anyways when I clicked ‘Compute from native bounds’ for Lat/Lon Bounding Box, it correctly translates from ‘Declared SRS’.
Maybe it is correct to display the Native Bounding Box in Declared SRS then. (weird)
Anyways the client (OpenLayers 3) displays the data correctly.
But another problem remains.
Integrated GeoWebCache refuses to cache the tile images.
When the logging is set to VERBOSE_LOGGING, it logs the following error:
org.geowebcache.grid.OutsideCoverageException: Coverage [minx,miny,maxx,maxy] is [0, 4097, 6143, 6143, 11], index [x,y,z] is [3101, 2791, 11]
Since the caching works correctly for the other layers that does not transform the source data (since the data is already in EPSG:5179), that must be the transformation problem. Or another one.
When I see the coverage area of the EPEG:3093 on the Demos / SRS List page on the GeoServer, the area seems to be wrong. (It does not even cover Tokyo!) http://epsg.io/3093 displays the correct one.
Is this the cause of the caching problem?
Does GeoWebCache look for the coverage of the SRS and rejects the out-of-bound request?
My GeoServer version is 2.7.1.1.
You should store your data in the native projection as GeoServer will automatically reproject the data when a client makes a request in a different projection.
Then caching and the bbox will work.
I've traced the source code from GridSubset.java to GeoServerTileLayer.java and found that the content of the gwc-layers layer file had wrong gridSubset extent coords minY value. (It was too high)
I don't know why... Since I manage the gwc-layers layer files using Git, maybe some file date inconsistency confused GeoServer to sync the values. Or maybe I just broke something. I can only guess... Now after changing that value, caching works.
What language or technology would I need to be able to create documents online? I want to be able to add text and images and move them into position, resize etc, similar to this.
And then when complete, create a PDF from them.
Sorry if this is a bit vague, I just need to know where to start researching.
You need to decide on your basic technology: Flash, Silverlight, Canvas, client-side SVG, server-side SVG or server-side bitmap. There are also commercial solutions that work with Adobe InDesign documents (and probably a host of other proprietary formats) but I'd expect those not to be cheap.
Flash/Silverlight require plugins, and are considered by some to be a dying technology - though I am sure that is disputed. Canvas is 'very HTML5' and is essentially a bitmap built/rendered on the client, but if you are ultimated rendering to PDF it may not provide the resolution you need. The same limitation affects building an image server-side too - you should probably be dealing with vector elements plus bitmaps, rather than rendering everything to pixels as you go.
That leaves SVG in my list, either on the client (see RaphaelJS) or on the server (see Inkscape). I'm doing some work with server-side SVG rendering at the moment, and it is promising; although subject to more scalability issues than client-side, it doesn't suffer from browser-compatibility issues or the limitations of browser rendering.
The biggest issue in browser SVG rendering is flowed paragraph text and text in/on a path - I am not sure how well these are implemented in modern browsers, or how much agreement there is between them. This is especially the case given that some of these require SVG1.2, and browsers (afaik) are only just settling on SVG1.1, after many years. But, if you just want to do standard blocks of text, bitmaps and vector elements, browser-based SVG should suit you fine.
The example you've given uses a server-side technology (SVG, or perhaps a commercial format) and renders to low-res PNG on the client.
In your case, once you've considered how to 'do the editing', you'll need to consider how to render to PDF, which will be done on the server. You could go low-level and use something like FPDF, use a report renderer like Jasper, or use a graphics system like GhostScript, Inkscape, Scribus, ps2pdf, svg2pdf etc.
Aside: I normally don't answer questions without obvious prior research. But, since you've indicated that you will indeed undertake this, I'm happy to help get you started.
We would like to display very large (50mb plus) images in Internet Explorer. We would like to avoid compression as compression algorithms are not what CSI would have us believe that they are and the resulting files are too lossy.
As a result, we have come up with two options: Silverlight Deep Zoom or a Flash based solution (such as Zoomify). The issue is that both of these require conversion to a tiled output and/or conversion to a specific file type (Zoomify supports a single proprietary file type, PFF).
What we are wondering is if a solution exists which will allow us to view the image without a conversion before hand.
PS: I know that you can write an application to tile the images (as needed or after the load process) and output them; however, we would like to do this without chopping up the file.
The tiled approach really is the right way to do it.
Your users don't want to download a 50mb file before they can start viewing the image. You don't want to spend the bandwidth to serve 50 megs to every user who might only view a fraction of your image.
If you serve the whole file, users will eventually be able to load and view it, but it won't run smoothly for most of them.
There is no simple non-tiled way to serve just a portion of an image unless you want to use a server-side library like imagemagik or PIL to extract a specific subset of the image for each user. You probably don't want to do that because it will place a significant load on your server.
Alternatively, you might use something like google's map tool to provide zooming and scaling. Some comments on doing that are available here:
http://webtide.wordpress.com/2008/08/27/custom-google-maps/
Take a look at OpenSeadragon. To make a image can work with OpenSeadragon, you should generate a zoomable image format which mentioned here. Then follow starting guide here
The browser isn't going to smoothly load a 50 meg file; if you don't chop it up, there's no reasonable way to make it not lag.
If you dont want to tile, you could have the server open the file and render a screen sized view of the image for display in the browser at the particular zoom resolution requested. This way you arent sending 50 meg files across the line when someone only wants to get an overview of the image. That is, the browser requests a set of coordinates and an output size in pixels, the server opens the larger image and creates a smaller image that fits the desired view, and sends that back to the web browser.
As far as compression, you say its too lossy, but if thats what you are seeing you are probably using the wrong compression algorithm or setting for the type of image you have. The jpg format has quality settings to control lossiness, and PNG compression is lossless (the pixels you get after decompressing are the exact values you had prior to compression). So consider changing what you are using as compression, and dont just rely on the default settings in an image editor.