QGIS » QGIS Application

The main WMS address is:

http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsambamm

I can't confirm the instant crash. But I confirm the crash when identifying the reprojected WMS layer and clicking on the result window when the format of the request is "feature", does not crash if the format of the request is "html" or "text".

I can't replicate with any other kind of file based raster, just wms, please leave feedback.

I forgot that with the projects attached in #5896-10

is easy to see also that the identify of reprojected wms layer returns wrong results.

It should be fixed in 96bd7e7 in master.

Giovanni Manghi wrote:

the correct BB is the one in the attached image, if in the reprojected layer you are seeing a different BB is because qgis is identifying the wrong feature (but it happens also with pixels of layers that on the server are rasters).

Now it is OK, in one moment it was giving to me wrong bbox for that area, cannot say why.

Radim Blazek wrote:

Giovanni Manghi wrote:

the correct BB is the one in the attached image, if in the reprojected layer you are seeing a different BB is because qgis is identifying the wrong feature (but it happens also with pixels of layers that on the server are rasters).

Now it is OK, in one moment it was giving to me wrong bbox for that area, cannot say why.

so this #5896 is fixed?

Giovanni Manghi wrote:

so this #5896 is fixed?

Fixed in master, not in 1.8. The bug is reported for both 2.x and 1.8.

Fixed in master, not in 1.8. The bug is reported for both 2.x and 1.8.

maybe the wrong identify when reprojecting wms layers is fixed but in master I see a regression (on master as well on 2.0.1):

Add this layer (postos de vigia)
crs=EPSG:3763&featureCount=10&format=image/png&layers=Postos%20de%20Vigia&styles=&url=http://mapas.dgterritorio.pt/wms/crif

from this server
http://mapas.dgterritorio.pt/wms/crif

in a new project, in one of the proposed CRSs and no reprojection.

• on qgis 1.8 indentify works
• on qgis 2.0.1/master the identify does not find anything

Fixed in master, not in 1.8. The bug is reported for both 2.x and 1.8.

I have just tested master (commit 4072e39227da578f6bd8f359a5197e6ea70ef874) and does not seems fixed. You can used the layers/projects you can find in #5896-9

or even with (in this case the identify does not work at all, works on 1.8)

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/DTM_75M.map

Giovanni Manghi wrote:

I have just tested master (commit 4072e39227da578f6bd8f359a5197e6ea70ef874) and does not seems fixed. You can used the layers/projects you can find in #5896-9

I was testing with wms_identify_201_reprojected.qgs from #5896-10, please confirm if it works.

I can confirm that wms_identify_master.qgs from #5896-9 does not work but that is different issue, not that described in this bug report. Part of the response:

<!-- WARNING: The value 'Pontos de Agua_layer' is not valid in a XML tag context. -->
  <Pontos de Agua_layer>
<!-- WARNING: The value 'Pontos de Agua_feature' is not valid in a XML tag context. -->
    <Pontos de Agua_feature>

it is using "Pontos de Agua_layer" as XML tag which is not valid. So if you want to support non valid XML (do you?) it should be new feature request, I think.

it is using "Pontos de Agua_layer" as XML tag which is not valid. So if you want to support non valid XML (do you?) it should be new feature request, I think.

why this is failing to identify (not reprojected) and in 1.8 works? Same reason?

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/DTM_75M.map

Giovanni Manghi wrote:

no, it does not. See attached images. The images refer to a identify click in that green feature in the middle of the map

11.png shows exactly the problem I had (and ask if it is server side), then it was working and now I can reproduce it again. Are you sure that the server including data was not touched?

Other polygons, like those red and green above are working ok, right? So it should not be request in wrong CRS, I think.

Do you have access to the vector data? Could you verify if the big area PT-35699 has a hole (island) where is PT-36085. My suspicion is that it does not, and sometimes the server finds first the bigger area on the background.

but it works in qgis 1.8. So from users point of view it is a regression, but I can understand that maybe it is not from another point of view. What do you think?

Solution could be that identify will show the error in results dialog and user will be able to switch to another format (text).

Giovanni Manghi wrote:

it is using "Pontos de Agua_layer" as XML tag which is not valid. So if you want to support non valid XML (do you?) it should be new feature request, I think.

why this is failing to identify (not reprojected) and in 1.8 works? Same reason?

http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/DTM_75M.map

Probably. The dots in layer name EL.DTM.75 are suspicious, however valid in theory.

The server offers text/plain and application/vnd.ogc.gml, 2.x prefers gml because it is expected to carry more information, unfortunately it is not valid. 1.8 is using text.

We have to show the error and give chance to switch format.

Are you sure that the server including data was not touched?

100% sure

Other polygons, like those red and green above are working ok, right? So it should not be request in wrong CRS, I think.

no it is not working ok. Today (on master) using the identify on this wms layer (reprojected) produces the result in the attached image: now clicking on a feature seems to identify also all the ones around it.

Do you have access to the vector data? Could you verify if the big area PT-35699 has a hole (island) where is PT-36085. My suspicion is that it does not, and sometimes the server finds first the bigger area on the background.

this is the vector
http://www.igeo.pt/gdr/Downloads/ProdutosCLC/CLC06_PT.zip

and yes, there are no overlapped polygons so where PT-36085 is then PT-35699 has a hole.

Solution could be that identify will show the error in results dialog and user will be able to switch to another format (text).

yes, this must be done then, because at this moment if the server does not support feature/gml then there is not way for the user to choose text and the result is that he thinks that the identify does not work or that the server has a problem.

We have to show the error and give chance to switch format.

agree

It should be fixed in de8a5d6.

When WMS is reprojected, the identify tool does not know context (extent,size) in layer original CRS and calls identify() without context. The provider was using full extent but small resolution.

Giovanni Manghi wrote:

yes, this must be done then, because at this moment if the server does not support feature/gml then there is not way for the user to choose text and the result is that he thinks that the identify does not work or that the server has a problem.

The problem is not if the server does not support GML (in that case it is used a different format) but when the response is not valid GML.

Fixed also the problem with invalid GML in d5f167f. The error is shown in results dialog and user can switch format.