(We are slightly changing the announcement format. Both base builds and cutting edge builds will now appear in the Cutting Edge forum area.)

9.0.181

manifold-9.0.181.zip

SHA256: 866a134fc14ef70181f21505f1425676f636c12e0e1559f269b10eb3ce856789

manifold-viewer-9.0.181.zip

SHA256: eb83fa071cc600f783a2be87f279c19c24d2ca553e6e223c85992c265e55d295

sql4arc-9.0.181.zip

SHA256: 348d3704101aa8aa424271ed304acee653e6390a4bd06e7cad32d82417842a65

Other install packages are available on the Product Downloads page.

Changes

The WMS service supports GetFeatureInfo. The output is JSON. The logic for determining the object under the cursor is the same as for the interactive web UI.

Cutting edge builds no longer expire.

End of list.

Appreciate the removing of expiring builds. I support several novice users and some struggled with the update process.

That also helps people who use cutting edge builds for production websites. It's really easy to forget to update a remote server. :-)

Nice to have you in Hong Kong. Good move. Same ocean at last.

Some tips for WMS users who want to try out the GetFeatureInfo request capability...

You can try out WMS requests in your browser. I'll use the demo site at https://manifold.net/ims9 for examples. Start by visiting that site in your browser to see what it's about, and try visiting the location for the Egypt eclipse.

A WMS GetMap request creates an image of a specified size that covers the specified bounding box. You can do a GetMap request to generate an image using standard WMS parameters to construct the URL that you enter into the browser, all on one line:

https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&CRS=EPSG:3857&BBOX=2950000,2620000,4000000,3700000&WIDTH=800&HEIGHT=600&FORMAT=image/png&

Click [here] to launch that link.

That creates an image roughly the same as the Egypt eclipse location in the HTTP site.

Things to note:

1. the image is a PNG that has transparency as a background, not the blue virtual background layer. That's so you can use the layers together with other layers from other sources. If you right click on the image and save it to a PNG file, you can open that file in photoshop or other editor and see how the ocean regions between country areas are transparent.

2. This is using WMS 1.3.0, in which OGC changed some of the parameter names. For example, in 1.3.0 the coordinate system is specified using the CRS parameter and not an SRS parameter.

3. The demo site is in Pseudo Mercator, which is EPSG:3857. The bounding box coords as minx, miny, maxx, maxy numbers are coordinates in Pseudo Mercator. The way I got those in the example was to draw a rectangular area in a Pseudo Mercator drawing as a layer in map with a Bing streets background layer (also in Pseudo Mercator) and then looked at the coordinates of the area's corners in the Info pane. If your map is in a lat lon projection like EPSG EPSG:4326 you can use lat/lon coords, like a bounding box of BBOX=-104,22,-100,26 for a region in Mexico.

4. You don't have to bother specifying the name of the map or layers.

GetFeatureInfo

Here's a minimum URL to get the attributes for what's under a spot located in the middle of the image created by the GetMap URL cited above (all on the same line):

https://manifold.net/ims9/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&CRS=EPSG:3857&BBOX=2950000,2620000,4000000,3700000&WIDTH=800&HEIGHT=600&i=400&j=300&

INFO_FORMAT=application/json&

Click [here] to launch that link.

It's the same URL but with a different REQUEST value, dropping the FORMAT parameter and instead specifying an INFO_FORMAT, and also specifying i and j parameters. WMS 1.3.0 uses "i" and "j" instead of "x" and "y" to denote the spot in the image of interest by numbers of pixels. If you're creating an image that's 800 by 600 pixels in size, a spot that's 400 pixels from the left margin and 300 pixels down from the top margin will be right in the middle of the image, where there is an eclipse path, so it reports the field values for that path at that spot.

The eclipses demo map has attribute data only for the eclipses and not for the countries or labels, so if you don't pick a bounding box for your image that includes an eclipse path and then specify a spot in that image that is within an eclipse path, there won't be any data to return and you'll get a blank return.

Why do they use pixel coordinates? That's because GetFeatureInfo is supposed to be used with tools that generate an image within some user interface and then people can click on a spot on the image and the app figures out where they clicked and then sends a GetFeatureInfo request to get the data that it uses to populate whatever info pane pops open to report the attributes for that spot.

When you're authoring maps to publish, read the server topic to learn how the Info tool gets data from whatever spot is clicked, so you know how to configure your layers and pick status for those layers so that attribute (field values) for objects will be returned for the layers you want, without anything being returned for layers you don't want to return data on a click.

setting the pick status to a layer works just fine with the IMS site.

But, when using something like QGIS, it only seems to work with the topmost layer (i.e. yellow layer in my example). So, it is cool that QGIS and ArcMap can now read WMS from a Manifold site, but it appears that GetFeatureInfo doesn't allow you to get data for other layers.

Attachments:
pickims.JPG
pickqgis.JPG

All is correct. The Info tool in a Server web site is different than a GetFeatureInfo request in WMS to the analogous WMS data source. It doesn't change any pickable status that's already been set in the Layers pane.

What determines how a GetFeatureInfo request works in WMS is set forth in the Server: WMS Server topic. As noted there, data is returned for the uppermost layer that is pickable as set in the Layers pane:

Important:A GetFeatureInfo request reports attribute data for the object at the i, jpixel location specified, ifthere is an object at that location and if the layer containing that object is the uppermost and pickable, as set in the Layerspane. If there is no vector object at that location in the component being served by Manifold Server, or if that layer cannot be picked, there will be no data returned. If there are multiple objects overlapping from more than one vector layer that can be picked at the i, jpixel location specified, attributes for the object in the uppermost layer will be returned.

So, if Q or Arc are connecting to the WMS site and using GetFeatureInfo, they'll be getting data for the uppermost layer that is pickable (see the Pick Mode section of the Layers pane topic).

Instead of directly returning the attribute data of the uppermost pickable layer at the i, j pixel location, could you implement that a) first a pop-up list with the pickable layers is displayed b) then on clicking one of these layers in the pop-up list have the attribute data at the i,j pixel location returned.

a) first a pop-up list with the pickable layers is displayed b) then on clicking one of these layers in the pop-up list have the attribute data at the i,j pixel location returned.

That's what the web GUI info tool does, not WMS. See the web GUI documented here. You can see how the demo web page operates by looking at it using the developer tools in your browser. If you want to create a web site that does the above using a GUI other than the one automatically provided, you can do that, for example, using the REST endpoints documented for the web GUI.

OGC WMS is a more primitive thing. See here to download the spec. If you wanted to duplicate what the Manifold web GUI does for you using WMS, you'd have to write all that, like the web code to create a pop up list and so on. Classically, I suppose you'd do a GetCapabilities to enumerate available layers and then in the GetFeatureInfo use a QUERY_LAYERS parameter. Lots of work.

That's not done with Manifold because a) it's way more efficient and quicker to use the REST endpoints on the web GUI, and b) the WMS data source (as can be seen from the GetCapabilities response) returns the whole deal as a single layer, so there's no QUERY_LAYERS parameter that should be used because it's only one layer.

I'd like to try this out the test website, but seem to be having difficulties.

When going to https://manifold.net/ims9 I get a 504 "Time Out" error. This is across multiple different time periods, so I assume it's not a periodic outage.

I am in the UK, slight complicating factor is I am using Firefox on the latest version of Ubuntu. I'm aware that this means I can't use Manifold, but not sure what difference it would make as a consumer.

Stephen

I assume it's not a periodic outage.

There were some periodic outages for updates and it looks like the last one was done wrong, leaving the public facing server disconnected from the outside world. It's online now.

Thanks for catching it!

I am in the UK, slight complicating factor is I am using Firefox on the latest version of Ubuntu.

Shouldn't matter. The server is in France, with no geofencing against the UK. Visiting the demo website doesn't require Manifold, just a browser, and connecting to the WMS data source doesn't require Manifold either - any WMS client, including those for Linux, should work.

Thanks, works now!

Hello

Since there hasn't been a version of M9 with major changes for almost 3 months, I was wondering, are we to expect a really big addition/change? I have in mind managing images "by pixel" instead of "by tile"...

Manifold's working on a very big project right now with all resources flowing into that. I expect that in a few months it will get back to routine builds.

Thank You for the confirmation/clarification Dimitri, I had been wondering the same.

Dare I ask if this is Manifold 9 related or a separate endeavor? I ask this as an invested Manifold user, as it would concern me if Manifold were going to be pulling all resources away periodically on unrelated projects.

It would have been nice to receive some sort of heads-up on the forum as few months ago as the last two builds came out with noticeably large pauses and without the usual slew of new features and fixes.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Everything that Manifold does is related to the product. Going forward the company has to invest massive effort to see if certain new ideas are possible and to do any refactoring required to support new ideas in general. With millions of lines of code that takes time. It's also a good time to do any general cleanup that's overdue.

To take a trivial example, anybody who's done a significant localization knows there are strings that are hardwired inside the product which are not localizable via a tag. There are a few hundred of those scattered in a very wide variety of settings where each has to be dealt with awareness how it might break something else far, far away in the code. It's not just a simple matter of adding another tag to the localization mechanisms.

Speaking of localizations, that raises another example, where some Manifold terminology clashes with what people prefer in some countries. A perennial request is that Manifold stop using the term "areas" and instead switch to using the term "polygons" as almost all other GIS packages do, reserving the term "area" for meaning a measurement in square meters or square feet. That would help avoid confusing phrases like "what's the average area of those areas?" which is clearer when written "what's the average area of those polygons?"

I raise that question because now's a good time to make that change, before the featurization campaign turns on again. (I've started a new thread to discuss "area" or "polygon")

Thanks for this info, I was wondering the same thoughts as Dan. People tend to fill in the gaps when there is silence. :-)

Any advice on what suggestions would be particularly helpful? I've been storing suggestions as issues arise. Some of which are things I've submitted in the past, but with perhaps a small twist. I don't like to be repetitive though, so I usually wait until there's enough new stuff before submitting and then let any repetition help in emphasizing. Good strategy?

Thanks very much for the clarification, Dimitri. It goes a long way to reassure those of us at this end of the internet who as Mike says have a tendency to fill in the blanks when things go quiet

Landsystems Ltd ... Know your land | www.landsystems.co.nz

It sounds as if this is the ideal time to make suggestions regarding perceived holes in the API and the programming model.

I will be making/renewing suggestions to allow read access to the layer selection(s) in the Project pane, and access to UI events such as mouse clicks (with object context).

(Strictly only the second would be necessary, yes.)