Subscribe to this thread
Home - General / All posts - wms only for raster not drawing ?
lionel
249 post(s)
#12-Nov-17 22:09

Hi

i have a wms url that show french cadastre area in vector mode using CODE INSEE that work in android locus Map software ( apk from google store = play store ) .

I see in manifold documentation that raster wms is supported by manifold gis but it seem not wms vector !!

Is it right ? ...I hope i wrong !!

Thank's

NB http://www.locusmap.eu/ ( really good software )

......for paris 13 the CODE INSEE value is 75113

......http://inspire.cadastre.gouv.fr/scpc/[codeINSEE].wms?service=WMS&request=GetCapabilities&

......http://inspire.cadastre.gouv.fr/scpc/[codeINSEE].wms?service=WMS&request=GetMap&

Attachments:
locusMap.png
manifold_WMS_vector.png

Dimitri


4,426 post(s)
#13-Nov-17 08:14

By definition, WMS provides raster data, not vector data. See the Wikipedia and other articles on web server protocols such as WMS, WFS, etc.

lionel
249 post(s)
#13-Nov-17 23:07

I know by reading most of your post that word has it own meaning and many people don't care about what they write ... it is my case here .

So my question should be : Does Manifold support WFS as a client ? some article in internet outline that we must test the WMS server with GetCapabilities request to see if WMS support WFS ( GML ?) .

From documentation : "" Manifold IMS not only publishes through HTML , it also is an OGC WMS server, an OGC WFS-T server and a full-power Image Server.""

I think Image server is a WMS without projection ? but i really don't know what mean those 2 words except both output word raster/image !!

I think manifold can be a client for WMS but not for WFS !!

the manifold doc index don't refer WFS http://www.georeference.org/doc/whgdata/whlsti0.htm#bm_W

the manifold doc cover only WMS http://www.georeference.org/doc/linked_images_from_ogc_wms_servers.htm

in a way the osm plugin return vector so need to write a script or plug in to retrieve and insert WFS data to manifold table colums .... with geom (I) !!

Regard's

http://www.mapserver.org/input/vector/wfs.html

http://docs.geoserver.org/latest/en/user/services/wfs/reference.html

Attachments:
Qgis_WFS.png

lionel
249 post(s)
#13-Nov-17 23:26

i ll try QGis but strange andoid osmAnd work !!

Attachments:
qgis_import_WFS.png

lionel
249 post(s)
#19-Nov-17 12:33

what is strange is that using the raster way i can see all the item available in the server but can't have access to the drawing layer on the server !!!

In menu : File -> Link -> Drawing should have WMS item to have acces to WMS vector layers ( ie WFS ! ? )

Android LocusMAp have acces to this layer but not manifold high end desktop software !!! ( it show layer name but can't process retrieve the data .. i cannot be happy like label side )

Attachments:
MAnifoldImageServer_WMS_vector.png

Dimitri


4,426 post(s)
#20-Nov-17 08:22

what is strange is that using the raster way i can see all the item available in the server but can't have access to the drawing layer on the server !!!

inspire.cadastre.gouv.fr has many server configuration errors. It is one of the test cases Manifold engineering has used to develop technical means in Future to get around server errors.

I don't remember if it was cadastre specifically or some other server (US government servers are often truly awful as well... NOAA comes to mind...) but a typical server error is when the server declares image tiles that it serves as being text and not images. If you try to connect to that server using a WMS client which honestly applies WMS standards, OGC says that is not supposed to work and with Release 8 it will not work. It doesn't matter that the layer is listed as it will not appear due to the server misconfiguration.

<rant>

Dealing with such server errors is not so simple, because however you do it you will anger some people. It is not so simple as just applying standards accurately and honestly. There is also a legitimate desire to extract all information possible even from broken data sources.

Release 8, for example, comes from a culture in which there was a greater focus on the value of standards. It was understood by all that ignoring the details of standards debased those standards, and that debasing standards in turn would eventually deny everyone the benefits those standards provided.

In that world, applying WMS standards correctly was praiseworthy and, instead of demanding that Release 8 be debased to lower IQ, folks would have focused their efforts on correcting the errors in the cadastre.gouv.fr server.

That approach doesn't work in the broader world of today, where the broadening of access to GIS, a good thing, has had the unfortunate side effect of not being accompanied by broadening of insight and education. So now, if people instantly don't get what they want they blame whatever is closest at hand, even if that is the thing which is functioning correctly.

Radian therefore automatically switches into slacker mode as necessary when connecting to the alphabet soup of web server "standards". It is a bit like how over the years Release 8 collected broken shapefiles, evolving the ability to decode a very wide "zoo" of files that claimed to be shapefiles but which violated the shapefile spec in all sorts of bizarre ways.

Radian is steadily building a zoo of configuration errors in web servers and is gaining greater and greater ability to guess when a server is making one of those errors and thus that error should be ignored.

There is a lot of risk in that approach, of course, since applying guesswork is necessarily imperfect. But that's life. You get no gold medals for honoring standards, but you get plenty of praise if you just connect to zillions of servers no matter how misconfigured those servers may be.

</rant>

To get around possible errors in cadastre.gouv.fr, try the latest edition of Future and see if it connects. Current Future builds already include many workarounds to server errors. The latest build (probably coming out today or tomorrow) might include even more.

If you ever find a "WMS" site (or one of the other alphabet soup web server standards) that the latest version of Future cannot use, please send in a bug report to tech support as discussed in the Bug Reports page. Engineering can then investigate and possibly expand the zoo of configuration errors for which there are workarounds.

adamw


7,444 post(s)
#21-Nov-17 14:30

Manifold 8 supports both WMS and WFS as a server, when you are publishing a web page.

Manifold 8 supports WMS as a client, when you are linking data from the web.

Radian / Viewer / Future support both WMS and WFS as clients, when you are linking data from the web. The support for WMS is much better than it was in Manifold 8: we support more image formats, we are much better at working with coordinate systems, we provide more caching options and these options work faster, etc.

Dimitri


4,426 post(s)
#21-Nov-17 14:55

what is strange is that using the raster way i can see all the item available in the server but can't have access to the drawing layer on the server !!!

Ah... cadastre.gouv.fr comes through again! :-) The problem you report is an error on the server side, a fairly typical ignoring of what the WMS standard requires. There is a straightforward workaround we can implement.

I filed a note based on what I saw in your screenshot... Engineering looked into this and what happens with that specific link is the following: the WMS standard says that if a server has limits as to extents for tiles or rasters it must advertise that. This server does not do that.

So... when Manifold connects and asks for tiles in the usual way the server replies "Bad request" and doesn't serve any tiles. If you ask for tiles (by happenstance or deliberately) to within allowed extents it starts serving tiles.

The server shouldn't be doing that, but it does, and the workaround is easy. We'll implement a checkbox or whatever, for servers that do not follow the WMS specification in this particular respect.

lionel
249 post(s)
#21-Nov-17 23:24

work for manifold future 163.8 and radian but not manifold 8 .

I don't know if the icon before "AMORCES _CAD Image" label are really image ? !!

so return data are really raster but white color appear transparent inside locusMap.

Attachments:
WMS_test_mf8bad_future-radian_OK.png

Dimitri


4,426 post(s)
#22-Nov-17 05:06

I don't know if the icon before "AMORCES _CAD Image" label are really image ? !!

If you connect to a WMS server it serves ONLY images.

work for manifold future 163.8 and radian

No. It works sometimes but not always. inspire.cadastre.gouv.fr is incorrectly configured. It does not follow the WMS standard in all required details, as I explained in my previous post.

If you drop a layer into your Future/Radian/FutureViewer map where the viewport request falls within the undocumented limitations of the server, then you get tiles. It seems to work OK. That is a happy accident. If your request does not fall within the undocumented limitations of the server, you get a blank display.

There are two possible solutions:

1. Contact the webmaster of the server and inform them of the error. You may think that is a waste of time, but I have discovered that sometimes the people who operate such servers are very receptive to bug reports and will quickly fix any problems at their end. It really depends on the person/situation at the other end. For example, if it is a contractor who operates the server for IGN or cadastre.gouv.fr the contractor might put all their effort into denying the problem, etc.. We all know how that goes.

2. Wait for whenever an upcoming Future build adds a workaround. Even if cadastre fixes this problem at their end we'll still add a workaround, because if it came up with cadastre it probably will come up with some other server. May as well add a workaround.

Misconfigured WMS servers are common. We want to provide defensive measures so that Future can connect to such things even when they are misconfigured or broken. We already have very many workarounds for broken WMS servers in Future so it is no big deal to add one more.

Dimitri


4,426 post(s)
#26-Nov-17 06:02

Cadastre as a server, using TMS and not WMS, is in the .map I published in http://www.georeference.org/forum/t139546.13#139578

Interesting to note that with .10 many of the servers which are misconfigured for WMS are better configured for TMS. A good example is the Argentinian "IGN" series.

lionel
249 post(s)
#26-Nov-17 06:42

the rendering is bad with Cadastre with mf 9.0.163.10 ( not my day luck ....random ? )

I really don't understand why cadastre fill color ( background color ? ) is white inside mf and transparency inside android locusmap ( see image link at the top of this post ) ? Is there a way to configure white to be rendering transparency inside mf ? how can i see the bings maps street map image layer locate behind cadastre layer !!!

Attachments:
JOSM sources _france_cadastre.map
JSOM_cadastre_tms_error.png

Dimitri


4,426 post(s)
#27-Nov-17 05:25

I really don't understand why cadastre fill color ( background color ? ) is white inside mf and transparency inside android locusmap ( see image link at the top of this post ) ?

Future shows whatever the cadastre server provides. "TMS" means "Tile Map Service." When you connect to a TMS server you get tiles, which are raster images. See the link inside the "comments" component in the project I provided - you can drill down into that link to see the original URL for the TMS server cadastre operates.

If you get images that show white in them those are the images that cadastre provides as tiles in that server.

If some other application shows just outlines with no background they are doing one of two things:

1) Most likely: they are connecting to a vector map server operated by cadastre. Vector services from IGN / cadastre are not free. Theyt pontificating about the wonderfulness of using free stuff should only apply to other people's products, and not, of course, to their own work effort. :-) IGN sells the good stuff. They don't give it away for free.

2) Less likely, but possible: Locus is connecting to different IGN server or are using some undocumented configuration option that has the server provide images that use alpha/transparency for background.

Dimitri


4,426 post(s)
#27-Nov-17 17:28

To follow up on the rendering... I just took a look and my guess is that cadastre is getting confused. From your locus map illustration I see you were looking at downtown Paris. Using the project I published I added the cadastre layer to the map with a Bing layer below, and then using Bing I zoomed into Paris between Gare Austerlitz and Gare de Lyon, centered on the Seine.

Turning on the cadastre layer, if you zoom in and out you can see that far zoomed in it almost certainly appears to be a tile problem from the server, where the boundary lines between different cadastral zones continue to appear correctly on the tiles but the tiles themselves are colored incorrectly.

Dimitri


4,426 post(s)
#27-Nov-17 18:36

how can i see the bings maps street map image layer locate behind cadastre layer !!

Sorry, I forgot to answer. Because the TMS layer is opaque where it is white (it is a raster layer, not a vector layer), you cannot see the Bing layer underneath it.

A possible solution: using the JOSM sources project, drag and drop the Locator Overlay layer above the cadastre layer. That will provide orientation. What I have done is put the Locator Overlay layer above cadastre and then I set the layer opacity of Locator Overlay to 50% so it is not so intrusive. Works great!

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.