Subscribe to this thread
Home - Cutting Edge / All posts - Radian Studio 9.0.161.x
adamw


10,447 post(s)
#25-May-17 19:01

9.0.161.x

Converted to a public update.

Changes for 9.0.161.4

Changes for 9.0.161.3

Changes for 9.0.161.2

Changes for 9.0.161.1

adamw


10,447 post(s)
#25-May-17 19:02

9.0.161.1

Changes

There is a new LAS dataport for LIDAR data sets. The dataport exposes LAS data as a table with the fields set up according to the LAS record type used in the file. There is an option to use LAS data as an ordinary drawing, but since LAS files usually contain millions or billions of records, the performance with the generic index is not going to be great. We are planning to add a specialized index for point cloud data in the future.

The LAS dataport can work with LAZ files, which are a compressed version of LAS files.

The LAS dataport analyzes the layout of LAZ files and caches uncompressed data accordingly. This significantly improves performance.

The 000 dataport supports ISO 8859-1 and ISO 10646 string values.

The query builder shows syntax for joins.

Dropping a layer with data into a map window with an empty map (either with no layers or with layers that are all empty) automatically zooms the window to the extent ot the new layer.

(Fix) The WFS dataport no longer requires the metadata for each layer to provide an URL for the GetFeature command (the standard allows specifying the default URL, the dataport now uses it correctly).

(Fix) Traversing a BTREEDUP or BTREEDUPNULL index in a MAP file in the order of decreasing keys no longer sometimes skips the initial key value.

(Fix) Double-clicking an error in a script window scrolls the script text to the error location.

The TileBuilder object supports IDisposable to allow extending it to contain resources that have to be disposed of explicitly in the future.

(Fix) The collections exposed by the Schema object have non-generic names, complying with the documentation.

The ExpressionParser.CreateExpression script function has a variant that does not take expression parameters.

The Expression.Evaluate script function has a variant that does not take expression parameters.

The table window shows boolean values as 'true' and 'false', the same format as accepted on input.

The query engine allows converting boolean values to numeric values and back via CAST.

The table window shows xN values with square brackets. Editing an xN value accepts them either with or without square brackets.

The table window can copy and paste individual values to the clipboard, via right-click menu. Attempting to copy or paste a value from the record that is being edited works with the values that have not yet been sent to the table. Attempting to paste a value into a record that is not being edited changes the record without putting it into the edit mode (and cancels all pending edits to other records if there are any).

The Set to NULL command used to clear the value of the edited record in the table window is renamed to Delete and can be used with records that are not being edited. Attempting to delete the value in a record that is not being edited changes the record without putting it into the edit mode.

Copying a table value into the clipboard allows pasting it as text into other applications (useful for viewing long strings). Pasting a table value from the clipboard accepts text copied from other applications.

End of list.

The API doc is updated to reflect all changes to the object model.

danb

2,064 post(s)
#28-May-17 02:33

The new LAS dataport is a great addition to Radian which I hope increasingly to use with our lidar holding. Are there any plans to add options to the dataport around per-filtering the data such as importing/linking first return ground strikes only or to thin the source cloud using some builtin options along the lines of those offered in PDAL (https://www.pdal.io/tutorial/dart-throwing.html)?

It would also be great to have options to treat a directory or directories of lidar files as a virtual point/grid mosaic as touched upon in this thread (http://www.georeference.org/forum/t136232.19#136249).


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

adamw


10,447 post(s)
#28-May-17 10:37

Our main focus with LIDAR currently is bringing all of the data in and handling all intricacies of input / output. That means supporting all features of the format, including accessing extension fields added on top of the basic records via VLRs, parsing coordinate system data encoded in different ways, supporting compression seamlessly, etc. After this is done, you will be able to analyze LIDAR data using queries and scripts although visualization tools are going to be slow on big data sets.

Then we can add tools and features specific for LIDAR. Sampling could be one of them.

Dimitri


7,413 post(s)
#28-May-17 12:24

To follow up on that...

Dan, that's a great question. Parallel computation in CPU and GPU plus parallel data access, both of which are Radian distinctions, fit naturally with anything LiDAR. You can't do anything if you don't have the data in the system so the first priority has to be, as Adam reports, handling all the intricacies of input / output. That all has to be done perfectly.

Beyond that, as always the key question is what specific features to prioritize. None of those are as difficult as the core parallelism; most are pretty simple. But to function correctly within a fully parallel system they all have to be written to fully parallel, thread-safe standards and that's a lot of work. Unfortunately, there are no shortcuts available by re-cycling code from PDAL. :-)

Anyone interested in LiDAR can help with that by sending in suggestions of specific capabilities you want to see in priority order.

dmbrubac


1,620 post(s)
#29-May-17 21:51

Great to see this addition - I will be trying it out as soon as possible and will try to put together some processing functionality, though to start I would say just look at what LAStools does - that tends to cover most of the basics.


Don't expect, suggest!

Dimitri


7,413 post(s)
#30-May-17 06:06

look at what LAStools does

LAStools are pretty cool, I agree. But collectively they cover a lot of ground (pun intended...). :-) What are the top three tools in the LAStools collection you think are the absolute most important?

If in the course of choosing those top three you wish you could add just two more LAStools commands, what would those two additional be?

For now, Radian and LiDAR are just at the very beginning. Bringing point clouds into Radian as point objects in maps certainly has some utility, but beyond that it will not be useful to anybody but programmers and SQL/Radian jedi until prepackaged Radian equivalents to things like LAStools (or, ideally, more visual point and click equivalents...) are introduced.

I will say, though that once you go through the initial time to load (amazing how big LAZ format expands to...), adding a geom_x rtree index, and then the scanning process to develop statistics that Style uses, it is very cool how quickly Radian can display and style zillions of points, coloring them by Z, etc. So even for someone like me who pecks at such data with basic dialogs it is possible to verify the data was imported correctly and to see the potential in terms of fundamental capacity. Even with an ordinary rtree index and not specialized indexes and other supporting infrastructure that are planned it is still surprisingly quick.

I have to say, 8 is cool but this is way faster. I'm so happy to be able to style something and then just save the project and the save is instantaneous. :-)

adamw


10,447 post(s)
#31-May-17 18:56

9.0.161.2

Changes

The LAS dataport parses coordinate system info from GeoTIFF tags (a variant of storing coordinate system info for LAS files).

The LAS dataport exposes classification table stored in the data set, if it is available.

The MFD, MIF and TAB dataports no longer sometimes fail to return data without .MAPCACHE.

GeomOverlayXxxPar and GeomOverlayTopologyXxxPar query functions no longer take the number of threads as a numeric value and instead take a JSON string with the description of a thread configuration. The number of threads is encoded in JSON as "threads". There is a new query function named ThreadsConfig which takes a number of threads and returns the JSON string with the thread configuration.

New query functions: GeomTriangulatePar and GeomTriangulateLinesPar, parallel versions of triangulation functions. The functions have the same parameters as their non-parallel versions plus an additional string parameter for the thread configuration. Accepted values in the thread configuration are: "threads" - desired number of threads, the default is 1; "batch" - minimum number of coordinates to allocate for a thread, the default is 1000.

New query functions: GeomVoronoiPar, GeomVoronoiLinesPar, GeomVoronoiPointsPar, parallel versions of functions building a Voronoi diagram. The functions have the same parameters as their non-parallel versions plus an additional string parameter for the thread configuration. Accepted values in the thread configuration are the same as for parallel triangulation.

The Transform dialog uses parallel versions of triangulation and Voronoi functions as long as the 'Allow using multiple threads' option is turned on.

Renamed script function: TypeConverter.GetType is renamed to TypeConverter.GetTypeClr.

Renamed script function: TypeConverter.GetTypeName is renamed to TypeConverter.GetTypeManifold.

Changed script function: Curve.Type now returns a string instead of an integer value.

Changed script function: Geom.Type now returns a string instead of an integer value. GeomBuilder.StartGeom now accepts the type of a new geom value as a string as well.

New script function: Tile.TypeClr returns pixel type as a .NET type object.

Changed script function: TileBuilder.StartTile now accepts pixel type as either the name of a Manifold type or as a .NET type object.

Changed script function: Value.Type now returns the name of a Manifold type. Value.TypeClr returns a .NET type object.

New script function: Schema.Field.TypeClr sets or returns field type as a .NET type object.

New script function: Schema.IndexField.TileTypeClr sets or returns pixel type accepted for a tile field as a .NET type object.

Renamed script function: the variant of TileBuilder.StartTile that takes an existing tile object is renamed to TileBuilder.StartTileCopy.

New script function: ValueSet.GetValueNames returns the names of all values as a string array (which can then be passed to one of the Table.SearchXxx functions).

Script functions working with .NET type objects are made unavailable for COM languages. (After the additions above this no longer harms functionality, because for each function taking a .NET type there is now a function taking the name of a Manifold type.)

Script functions that have multiple variants can be used from COM languages. (Previously in these cases all but one variants were getting renamed, and the writer of a script in a COM language had to guess the name of the variant he needs. Eg, instead of ValueSet.AddValue, one had to call ValueSet.AddValue_2.)

Script functions that take arrays as parameters accept arrays created by COM languages (in VBScript, Array(x, y, z)).

Script collections can be used from COM languages. Collections that allow indexing by integer or string value determine which particular type of indexing is being performed by a COM client at runtime. All collections expose the EnumObj property which returns an object that can be iterated by a COM language using For Each (instead of writing 'For Each field in schema.Fields', write 'For Each field in schema.Fields.EnumObj').

The Delete command in the layer context menu is renamed to Delete from Map.

The Toggle command in the layer context menu is renamed to Visible and has a checkmark indicating whether the layer is shown or hidden.

The layer context menu includes the Open Table command to open the table with the layer data.

End of list.

The API doc is updated to reflect all changes to the object model, except notes on using EnumObj to get For Each in COM languages.

Dimitri


7,413 post(s)
#31-May-17 19:48

There is a new query function named ThreadsConfig

A minor typo: Should be ThreadConfig. It is correct in the query builder template.

Dimitri


7,413 post(s)
#01-Jun-17 15:48

Don't know if anybody else has noticed, but the triangulation is very quick. Trying just a single thread, Radian does in three seconds what takes PostGIS 390 seconds. It will be interesting to see how that all plays out.

adamw


10,447 post(s)
#01-Jun-17 15:56

Expanding a bit on Dimitri's post above, here are some numbers illustrating performance improvements in triangulation.

Triangulation, 5 million points.

Measuring a full transform, that is, collecting each input coordinate from an object in a drawing and putting each produced triangle into a drawing, creating a new object / record.

8.0.30 - 458 sec

9.0.161 - 405 sec (improvements from better data organization in Radian)

9.0.161.2 - 300 sec (optimizations in the algorithm), 1.35x faster than 9.0.161 and 1.53x faster than 8

9.0.161.2, multiple threads (4) - 181 sec (using multiple threads), 2.24x faster than 9.0.161 and 2.53x faster than 8

...and if we measure just the triangulation part cutting out the time spent collecting input and composing output, the numbers are:

9.0.161 - 343 sec

9.0.161.2 - 238 sec, 1.44x faster than 9.0.161

9.0.161.2, multiple threads (4) - 119 sec, 2.88x faster than 9.0.161

The improvements for computing Voronoi diagram are about the same.

Test data set (zipped SHP so you can try it in other tools as well, the closest equivalent to the Triangulate All transform in QGIS is probably Vector - Geometry Tools - Delaunay Triangulation, in PostgreSQL ST_DelaunayTriangles + merging + splitting, etc... be sure to run a subsample first to gauge the performance):

triang.zip

Dimitri


7,413 post(s)
#02-Jun-17 11:56

I was curious to see how vast ArcGIS Pro does this but I can't even get ArcGIS Pro to load the data. Either that or giving up on the load after an hour is giving up too soon. The triang data set has over 5 million points. I'll try with a smaller subset.

In the meantime, if anybody who knows what they are doing with Arc wants to try this and report speed with various Arc configurations, that would be an interesting comparison.

mdsumner


4,260 post(s)
#01-Jun-17 17:33

"GeomTriangulateLinesPar" is a new name for constrained triangulation? And we would triangulate polygons by coercing first to lines, then post-filter/classify triangle centroids against the input boundaries? (there's not many packages that can even do this at all, only CGAL, Triangle, JTS (via Siedel) - let alone parallelized). :)


https://github.com/mdsumner

adamw


10,447 post(s)
#01-Jun-17 17:36

All of GeomTriangulateXxx functions will do constrained triangulation when passed a line or area geom, but constrained triangulation is not yet parallelized (it is going to be, "watch this space", etc).

PS: A number of improvements to triangulation in 9.0.161.2 apply to constrained triangulation as well, yes. See the numbers comparing 9.0.161 to 9.0.161.2 with a single thread. Just not parallelization yet.

artlembo


3,400 post(s)
#01-Jun-17 17:47

Another important triangulation tool is the decompose to triangles function in 8. This can bust really complex polygons that span very large geographic areas into smaller pieces to take advantage of spatial index capabilities. It is one of the methods for restructuring data when planning to tackle big data problems. I have a blog post here, and a video here.

adamw


10,447 post(s)
#01-Jun-17 17:58

We are almost there. The only difference from GeomTriangulateXxx that we have now and Decompose to Triangles in 8 is that the former does not remove triangles outside of the area. We will extend the code to remove them via an option.

mdsumner


4,260 post(s)
#03-Jun-17 02:08

DecomposeToTrianglesAdv was 8.0's most under celebrated function. Can we also have minimum angle / minimum area? Or is that best done by segmentizing the lines under various rules?


https://github.com/mdsumner

adamw


10,447 post(s)
#03-Jun-17 11:23

Can we also have minimum angle / minimum area?

Could you elaborate a bit? If you are looking for a function that would decompose an area into a set of triangles with a limit on the minimum angle / area, that's not possible without adding extra coordinates. And if we are talking about adding extra coordinates, we need to know where the criteria comes from. (As in, it might be best to do something silly like split the area with a rectangular grid and triangulate just the small parts to begin with.)

mdsumner


4,260 post(s)
#03-Jun-17 12:55

Ok, I thought Steiner points a la Shewchuk was pretty standard, I'll look into it some more.


https://github.com/mdsumner

adamw


10,447 post(s)
#16-Jun-17 19:21

9.0.161.3

Changes, short version: support for LAS to LAS with filtering / changes in between, performance improvements in triangulation expanded to constrained triangulation, reworked dialogs for creating new components, all features of the .NET object model supported in COM clients.

Changes

(Fix) Map window no longer sometimes continuously blinks in the presence of layers referring to non-existing tables or fields.

Parsing a coordinate system from WKT recognizes additional WKT sequences (FITTED_CS, etc).

LAS dataport exposes extra fields added via variable-length records.

LAS dataport can export table data as a LAS or LAZ file. Record type is deduced automatically from the supplied fields.

(Fix) Attempting to perform a compacting save on a SHP file in the same location no longer fails.

(Fix) Attempting to update a batch of records in a MAP file table disallows altering values of the key fields for the index used to update.

GeomTriangulateXxx functions can use multiple threads when triangulating lines or areas (constrained triangulation), and perform significantly faster even with a single thread. Triangulating an area only keeps the triangles inside the area (to get the previous behavior, which was to keep all triangles in the convex hull, convert the area to a line prior to performing the triangulation).

New Transform dialog template: Decompose to Triangles - decomposes areas to triangles.

The new Edit - Export Results command allows exporting the results of a query. (This can be used to export a subset of a LAS file as a new LAS file, for example.)

The New Xxx dialogs used to create new components no longer show target folder path and no longer include means to specify description. If a new component is created in the context of the root MAP file, the data source path is hidden as well, otherwise the dialog shows the info regarding the target data source in a special area at the top. The OK buttons are renamed to Create <component type>, made larger and moved to the left, similarly to Transform, Select and other dialogs.

The New Xxx dialogs used to create new components include the Edit Query button. The button generates the query for the dialog actions without performing these actions.

The New Xxx dialogs used to create new components check names of components and fields prior to performing any operations, to fail early instead of mid-way through a create sequence.

The New Table dialog edits table schema using the standard Edit Schema dialog. If the target data source is not a MAP file, the dialog sets initial table schema to use an INT32 ID field (instead of an INT64 MFD_ID field) and a BTREE index on that field.

The New Drawing dialog is reworked to ask for the name and type of the geometry field, the coordinate system, and whether or not to create a spatial index. If the target data source is not a MAP file, the identity field is an INT32 field named ID, similarly to New Table.

The New Drawing dialog allows creating a drawing based on an existing table and geometry field. If the specified geometry field does not have an associated spatial index, the dialog suggests creating one. The coordinate system associated with the field can be edited.

The New Image dialog is reworked to ask for the names and types of the X and Y fields, the name, pixel type and size of the tile field, the coordinate system, the initial rectangle of the image and whether or not to create a spatial index. If the target data source is not a MAP file, the identity field is an INT32 field named ID, similarly to New Table.

The New Image dialog allows creating an image based on an existing table and tile / X / Y fields. If the specified combination of fields does not have an associated spatial index, the dialog suggests creating one (an RTREE index on X-Y-tile fields is used for MAP files, a BTREE index on X-Y fields for all other data sources). The coordinate system associated with the tile field can be edited. Using the same field for X and Y is disallowed.

The New Image dialog allows creating an image based on an existing image, adjusting its bounds. The new image uses the exact same fields and indexes as the original image. If the original image uses a level field, the dialog shows its name and type.

The New Image dialog verifies the bounds of the new image to be valid.

The New Labels dialog is reworked to ask for the name and type of the display field, and the coordinate system. The created drawing uses a GEOM field and includes a spatial index. If the target data source is not a MAP file, the identity field is an INT32 field named ID, similarly to New Table.

The New Labels dialog allows creating a labels component based on an existing drawing.

Invoking the New Drawing dialog from the Project pane via right-clicking a table automatically selects the clicked component in the dialog. Right-clicking a drawing or labels automatically selects the producing table as long as it is in the same data source.

Invoking the New Image dialog from the Project pane via right-clicking a table or an image automatically selects the clicked component in the dialog.

Invoking the New Labels dialog from the Project pane via right-clicking a drawing automatically selects the clicked component in the dialog. Right-clicking a labels component automatically selects the producing drawing as long as it is in the same data source.

The names for new components suggested by the New Xxx dialogs are cleaned up from component type postfixes and short numeric postfixes like '2' in 'Labels 2'.

New script functions: Application.CreatePoint, Application.CreatePoint3, Application.CreatePoint4 create point objects. Application.CreatePointObj, Application.CreatePoint3Obj, Application.CreatePoint4Obj create point objects that can be used from COM clients ("regular" point objects use generic types that can not be used by COM clients directly, the new functions return wrapper objects that can be used to work with underlying generic point objects).

New script functions: TypeConverter.ConvertObj, Value.DataObj, ValueSet.AddValueObj take and return point objects from COM clients.

Changed script functions: constructors for curve objects have been replaced with GeomBuilder.AddCurveCircle, GeomBuilder.AddCurveCircle3, GeomBuilder.AddCurveEllipse, GeomBuilder.AddCurveEllipse3, GeomBuilder.AddCurveSpline, GeomBuilder.AddCurveSpline3 functions that can be used from COM clients.

New script functions: CurveCircle.CoordObj, CurveCircle3.Coord3Obj, CurveEllipse.CenterObj, CurveEllipse.CoordObj, CurveEllipse3.Center3Obj, CurveEllipse3.Coord3Obj, CurveSpline.CoordObjs, CurveSpline3.Coord3Objs take and return point objects from COM clients.

New script functions: Geom.Branch.CoordObjs, Geom.Branch.Coord3Objs, Geom.CoordObjs, Geom.Coord3Objs return point objects to COM clients.

New script functions: Tile.PixelObjs, TileBuilder.PixelObjs take and return point objects from COM clients.

New script function: PropertySet.EnumObj exposes a enumerator for COM clients.

New script function: Database.GetComponentType returns type for component with a specified name.

New script function: Application.GetTechnologyForFile attempts to detect technology for a file with the specified name.

New script function: Database.ExportFile exports a component to a file with the specified name, detecting export technology from the name.

New script function: Sequence.Recompose takes a sequence and returns a new sequence with rearranged or filtered output values. The function is used with batch updates.

End of list.

The API doc is updated to reflect all changes to the object model.

(As of this build, the object model for .NET exposes all of its features to COM clients. See the API doc for details.)

tjhb
10,094 post(s)
#17-Jun-17 01:57

This is my favourite bit so far (really elegant)--

Triangulating an area only keeps the triangles inside the area (to get the previous behavior, which was to keep all triangles in the convex hull, convert the area to a line prior to performing the triangulation).

followed by enhancements to the New component dialogs--the Edit Query button, and being able to use an existing a component as the basis wherever that is meaningful.

Great to see examples in IronPython and VBScript! Thanks so much for starting this in-house. (Do you want more?)

The headers for the alternative examples in C#|VBSCript|IronPython don't display so well in Firefox 64 (v.52 esr), just as plain text, but clicking on the text does work, just like the tabs in IE and Edge.

Attachments:
Edge.png
Firefox.png
IE11.png

adamw


10,447 post(s)
#17-Jun-17 07:14

Thanks.

We will translate all examples to VBScript / IronPython over time. All new examples are written in all three languages from the beginning as well. This helps us make sure we don't introduce any features that are inaccessible from one or more of these languages. We will do the translation of existing examples ourselves, but thanks for the offer to help.

We will look into fixing the tabs for Firefox, thanks for letting us know they don't look right there!

Dimitri


7,413 post(s)
#17-Jun-17 08:02

Tabs look great in Opera.

[I love the way Opera automatically blocks ads (faster browsing without downloading all that spam...) and the built-in VPN, too. ]

tjhb
10,094 post(s)
#17-Jun-17 23:50

Firefox is fixed already! Looks great.

tjhb
10,094 post(s)
#18-Jun-17 00:26

The reason why I think this is so elegant--

Triangulating an area only keeps the triangles inside the area (to get the previous behavior, which was to keep all triangles in the convex hull, convert the area to a line prior to performing the triangulation).

--is that it treats data not only as data, but also as its own metadata.

We pass in areas, we get a result pertinent to areas. We pass in lines, we get a result pertinent to lines. (We pass in points, there is no choice.) Very like "quiet cockpit" design. So cool.

KlausDE

6,410 post(s)
#18-Jun-17 18:32

Here is the german localization for 9.0.161.3

Attachments:
ui.de.txt


Do you really want to ruin economy only to save the planet?

jockeryl
178 post(s)
#08-Jul-17 04:53

Is the "Decompose to Convex Parts" Transform added to Radian? It's very slow and crashes Manifold 8.

I have to selected parts of the data and decompose piece by piece to avoid the crashes.

Based the improvements for Decompose to Triangles in Radian, I think the Convex Parts should work much better in Radian. Can I vote up that Transform to be added?

Same goes for the Normalize Topology Transform with Tolerance 0.5m, it's very slow in Manifold 8, my script spend 95% of the time processing that transform.

jockeryl
178 post(s)
#08-Jul-17 05:58

I upload a sample MAP with 1 complex polygon that needs to be transformed into Convex Parts. Each time I try the transform it crashes Manifold 8.

It also crashes if I try to Transform to Triangles in Manifold 8.

All the other areas in my dataset worked fine, this last piece is around 10% of the total data.

I just wonder what is wrong with this polygon that cause the crash.

I can create triangles with Radian in 7sec with this polygon, but I'd like Convex Polygons as a mesh for the next step in the process. The whole process is scripted in Manifold 8 and deployed on a server.

If anyone could help to verify this in Manifold 8.0.30 then I can email this to support.

Attachments:
Area to be Transformed into Convex Poly.map

Dimitri


7,413 post(s)
#08-Jul-17 07:16

This is a thread about a new cutting edge build for Radian. If you want to start a conversation about something in Release 8, please repost in a new thread.

adamw


10,447 post(s)
#08-Jul-17 07:31

As Dimitri says, this should have been posted to General.

We are adding Decompose to Convex Parts to Radian, yes. I checked the MAP file you attached to the other post, the new algorithm that we are merging to Radian handles it without issues (and fast).

We are planning to improve Normalize Topology as well. We already have it in Radian and there are several performance improvements compared to 8, but they are small, we have plans for much bigger improvements.

jockeryl
178 post(s)
#08-Jul-17 09:21

Sorry, I was referring to the new Transform in the latest release that I tested:

My intention with the post was to highlight a feature that works in R9 but not with M8, to Transform Triangles, as well as indicate the need for the currently missing feature, Transform Convex Parts.

Thanks for the confirmation that this issue will go away in a later version.

I'll worked around it at the moment. I split the map in smaller selections and used Transform on a smaller subset.

adamw


10,447 post(s)
#21-Jun-17 19:27

9.0.161.4

This is a slightly unusual cutting edge build.

We are introducing a new product configuration - Manifold Viewer.

Manifold Viewer is a reduced version of Radian Studio that is going to be available free of charge. Manifold Viewer will be able to open all types of data sources, including MAP files created by both Manifold 8 and Radian Studio. It will be able to view data and analyze data using queries, but will not be able to save changes to MAP files or export data to any format.

Limitations:

  • No saves of MAP files.
  • No exports.
  • No ODBC driver.
  • No scripts and no add-ins.
  • No GPGPU.
  • Data sources other than MAP files are read-only, except for mfd_meta.

Usability changes dictated by read-only mode:

  • .MAPCACHE files are forced to be temporary.

Manifold Viewer will co-exist with any existing versions of Radian Studio and / or Manifold 8.

Updates to Manifold Viewer will follow updates to Radian Studio.

Important: the provided cutting edge version of Manifold Viewer requires a working license of Radian Studio. Public versions of Manifold Viewer will not require any licenses.

Changes

(Fix) Connecting to a data source set to use a temporary .MAPCACHE file no longer reports that cache is going to be rebuilt.

Localized strings may include '{productname}' escape sequence that expands to product name.

Product icon includes hi-res versions with true transparency.

Installation packages include Visual C++ runtime modules. Installation packages are now EXE instead of MSI.

The About dialog reports the name of the available GPGPU device, if there is only one.

End of list.

Download links (portable ZIPs are included, but we really want as many people as possible to try EXEs):

manifold-9.0.161.4.exe

SHA256: f5956fdb 2cd5c4b0 87a65c19 4d032a04 f8558ff8 ef03c899 4ba396f7 76ca4483

manifold-9.0.161.4-x64.exe

SHA256: 479cbd01 14ce9cbf 3e2992a3 3d8b54e6 8f13a6d3 53f5e263 24a168cd bc7a03cd

manifold-9.0.161.4-x64.zip

SHA256: 93c73caf d2366f1a 96805ddb 2e45b741 4715d602 c24f4a96 d5a60940 27ad047d

manifold-viewer-9.0.161.4.exe

SHA256: 18756f69 0d716a83 0ce2b63e fd2eb358 25aac45d 18b157ff ba4a7304 fbf807d0

manifold-viewer-9.0.161.4-x64.exe

SHA256: a956f5bc dc8b27e2 3a1847a4 a14df4d6 fa6d8992 5685ef0a 322fb724 c692db01

manifold-viewer-9.0.161.4-x64.zip

SHA256: aecbf75c 8895f105 69724f5d 1645aff1 70f3d3e5 ae9f8f78 3043d03f f4b566bd

Tell us what you think!

adamw


10,447 post(s)
#21-Jun-17 19:31

One more thing:

Manifold Viewer uses the exact same localization files as Radian Studio. German localization posted by Klaus above is directly applicable.

artlembo


3,400 post(s)
#21-Jun-17 22:27

wow. 5 minutes in, and I'm loving it! This should eliminate questions like:

do you offer a free version

Literally, within the first 5 minutes I opened a .map file, then I opened a SQL Server data source, and then issued the EXECUTE [[....]] ON [Data Source] function, and wow - Radian Viewer even can call on SQL Server.

This really changes things up. It really is a generous overture to the community.

artlembo


3,400 post(s)
#21-Jun-17 22:32

ok, now 10 minutes in. This is really great :-)

tjhb
10,094 post(s)
#21-Jun-17 23:15

What a great idea! And Art's "generous overture" puts it perfectly.

The whole of Manifold spatial SQL, and universal access, for free! I can't imagine anything better.

Now we can offer massive quanitites of data to clients who have never used Manifold products, and say--well, just open it. You want to know... X? Try this query. Now open this child database. Yes, we can build that.

I think it will make the upgrade to the full Radian Studio (later, Manifold 9) a very easy sell.

I don't know anything about marketing, but this is really clever.

(How about slowing down the nice new splash screen? Just enough to read it.)

Dimitri


7,413 post(s)
#22-Jun-17 09:55

It's great to hear the positive feedback! As to marketing...

[Edited to keep it simple...]

Should anything else be changed in Viewer? Fewer limitations or greater limitations?

I have to say, by the way, that one of the coolest things about the Manifold community is that it is one of the few communities where you can ask such questions and trust to the integrity and foresight and shared responsibility of all in seeking advice.

Mike Pelletier

2,122 post(s)
#23-Jun-17 22:25

Well I couldn't be happier about having a viewer version. Having it free is even better. It's great that it can import all the data types.

The big problems I see is not being able to save your efforts setting up the project, poor labeling, and no info tool. If someone goes to trouble of installing the software and they have the ability to format and import layers, then they should be able to save the project and reuse it again.

I suppose the idea is to have someone with RS setup a nice project for them to use. That's fine but I think folks will be very frustrated in taking the time to modify or setup their own project and then find out they can't save it.

Also, a viewer should be able to see the information and easily pull out the information. In my mind, that means a decent labeling engine and an information tool for clicking on objects.

People will be wowed by the ability to see all the different layers but will be saddened to see how difficult it is to pull out information. These arguments were made during beta for RS and I think the current design was deemed acceptable because RS is meant for sophisticated DBMS folks.

Who is the viewer meant for? I'm hoping it is meant for use like other GIS viewers in the past.

The new youtube video from Manifold Sales about the viewer shows an example of triangulating many points. That's great for showing the speed but it's not a normal function for a viewer. As it stands now, I'm thinking the viewer is meant to allow me to share with others what kind of things RS can do. If they want to do some actual analysis they need to be able to save. If they want to pull data out of the map, they need some more tools.

Hope that is helpful.

hugh
200 post(s)
#23-Jun-17 23:24

I agree that a "viewer" might be expected to have an info tool that a less experienced user could readily access. However I would think Radian Viewer would interest a more experienced GIS person who wants to try out the power of Radian. In my situation I would like to get some of the GIS pro's where I work interested in Radian so they can do their job better, freeing me up to do my mostly non-GIS work. I can demonstrate Radian to them on my own computer and then the Viewer will be great for them to be able try out its capabilities at their skill level. "Viewer" might not be the most accurate thing to call it, but it does convey the limitation on saving work. Calling it a "Trial Version" would be more misleading I would think.

Dimitri


7,413 post(s)
#24-Jun-17 07:58

If someone goes to trouble of installing the software and they have the ability to format and import layers, then they should be able to save the project and reuse it again.

I agree 100%. That's exactly why Manifold sells Radian Studio at a very low price, to give people that capability if that is what they want. :-)

The new youtube video from Manifold Sales about the viewer shows an example of triangulating many points. That's great for showing the speed but it's not a normal function for a viewer.

Very true, but only if you have limited expectations of what a "viewer" can do, like not being able to do any analysis. But why should Manifold dumb down what Viewer can do just because other "viewers" do not have, say, SQL? You may not use triangulation, but other people might use it, to construct something to feed into SQL. Lots of people will use the Buffer transform in an ad hoc way, for example. And, it is cool to show the speed.

As to the video... that's why I referred to it as a beta test. :-) We should do some videos that show cool SQL being used to analyze data in sophisticated ways, either from a DBMS or in the context of spatial matters. Suggestions?

By the way, nothing about Viewer prevents you from doing very sophisticated SQL (keep it in Notepad if you want and copy/paste into Viewer) upon data to extract meaning and insight from spatial data. Can't do that with "uh... all I can do is show a pretty picture" viewers one often encounters.

Viewer may be read-only with data sources, but you can copy/paste to and from the Clipboard, so you can do things like copy/paste text and even components to and from between Viewer and Radian. :-)

I'm hoping it is meant for use like other GIS viewers in the past.

Yes and no. No, because GIS viewers in the past have been more limited and Viewer is far beyond GIS. It does database too in a way that very few "database browsers" can approach. GIS viewers have zero capability to do sophisticated SQL things with Enterprise DBMS, for example.

Yes, because many GIS viewers in the past have been prompted by requests from users of the full GIS, for the company to provide a free viewer that would add to the value of the GIS product they had already licensed. That was a stimulus for Viewer as well.

I'm thinking the viewer is meant to allow me to share with others what kind of things RS can do

You can use it for that, of course, but that was not the prime stimulus. It really was not at all prompted by any desire to have a "trial" version. If that were the task it would have been different, like a classic timed trial or whatever.

Viewer happened mainly because of the profound reaction to Radian .map format. Over and over we kept hearing "this is so totally cool... I can do all this so fast with a fast mix of huge rasters, vectors and tables...and I can nest it, and I can... I wish I could share this, even just for viewing, with others..."

And that is so totally true. Take the Boston image in the video. Just try opening a 36 GB image in PhotoShop, just to look at it, not even to do anything with it. You'll tear your hair out in frustration. With Viewer it's a snap - opens instantly, browses instantly. Being able to store very large, very rich data in a convenient .map format that totally and completely preserves the value of the data inside in a sophisticated way, including all spatial details and context, is a really big deal. Being able to leverage that for free is revolutionary.

There are endless applications for Radian users that having Viewer makes possible.

Here's one: Suppose your hobby is finding meteorites. The best way to do that is to follow three rules: 1) Hunt in the desert where lots of plant cover doesn't get in the way of seeing rocks that are laying on the surface. 2) Hunt on light, hard desert surfaces where dark rocks (meteorites are almost always dark) are obvious from far away and where they will lie for thousands of years after falling without sinking into sand. 3) Hunt within the ellipse of a known strewn field, since meteorites usually fall in groups when the main mass fragments as it hits the atmosphere.

To do the above you need maps that combine vector information on strewn fields with road information and detailed photos, and that has to be offline since such wild areas usually do not have cell phone service for Internet. You need detailed georegistered photos to find your way in very wild country or to plan a path you can drive to get to a dry lake or whatever. Publish a Radian project with the huge image as your detailed photo background plus all the layers you want for access roads, trails, strewn fields and more, and then your friends and fellow fanatics can use a free Viewer to look at it in the field on a Windows tablet. You can do the same thing with archaeological interests, hunting the remains of trenches from WWI in Europe, prospecting for minerals and much, much more.

You might say, "OK, all that is cool but it really is a super benefit for people who have Radian," and the reply is, Yes! If all Viewer does is deliver yet more value to people who have licensed Radian it is worth doing. Manifold wants to deliver the maximum capability it can to customers. That's why updates are free and why it is worth doing things like Viewer to enhance the value of a license to customers. Viewer will deliver the same benefits to anything built on the Radian engine, for example like Release 9. That's a good thing.

On top of that, if Viewer can do great things for others who are not yet Manifold customers, well, why not? And that it can, way beyond the limited vision of "viewers" from times past, in ways far beyond just being able to leverage Radian technology .map format.

Viewer can connect to hundreds of data sources, including basically every enterprise class DBMS on the planet (millions of organizations and data stores), vast variety of cloud storage things, endless web servers in all the popular formats and hundreds of formats covering pretty darned much every format ever used for photographic images of any kind, rasters of any kind, vectors, and database information. That's infinitely more than just opening a Radian .map and it is way more than any other "viewer" that I know.

In that way it adds value to people who use all sorts of different other packages, from MapInfo to ESRI (dig through Geodatabases beautifully with Viewer...) to SQLite to GPKG. What's not to like about that? :-)

What you usually encounter in a free viewer is something that is wired up to show what it can get through GDAL/OGR. That's a lot, and it is useful for sure, but it is very different from something that also wires up DBMS smarts at the same time, and ultimately is not remotely as much as what Viewer can connect to, and not remotely as easily as Viewer can connect, and not as fast given CPU parallelism and not as robustly as Viewer.

Beyond simply viewing what is in a data source, there is no free viewer that comes remotely close to the level of analytics or DBMS smarts made possible within Viewer. Just ain't there. No spatial SQL, no zillions of spatial and other functions. You could, of course, install a FOSS GIS ensemble of things like QGIS and PostgreSQL to get a lot (but not all) of that, but then you are getting into elaboration many people do not want and which is way beyond the convenience Viewer provides to either view a shapefile or open a table in an Oracle Spatial database. People who have such complex interests they are willing to install, say, PostgreSQL, will find it more cost-effective to simply use Radian.

As for Viewer having many capabilities far beyond what limited "viewers" have, so long as the basic import/link process is simple so people can easily do that and look at what they want (it is), the rest of it doesn't get in the way of simple viewing.

Beyond that, if we made the effort to lobotomize Viewer it never would have happened, because that requires a huge amount of effort. And to what purpose? So that people have a more limited tool? If they can use the extra stuff, so be it and all the better. At the very minimum it helps our Radian licensees get more value and that is a "must have" for Manifold, to deliver a better product and more capabilities for our customers at a lower and lower cost. Hard to beat "free" in the lower cost end of that equation.

The only reason to remove something, I think, is if having it in Viewer kills the tree that bears the fruit, that is, if it removes any reason to ever buy anything. But given the value in something like Radian you can go a very long way with a hugely capable Viewer and give people a lot for free without harming the tree that bears the harvest. You can pick a lot of apples without having to chop off any limbs. If you have a bountiful orchard you can give away a lot of apples to your friends and to your community with good karma for all.

Thanks for the comments!

adamw


10,447 post(s)
#24-Jun-17 08:53

The big problems I see is not being able to save your efforts setting up the project, poor labeling, and no info tool.

We disagree on not being able to save (this is what makes a viewer a viewer and not a full product, we think splitting the functionality this way makes sense), but we agree on the rest.

We are working on the info tool as we speak. This was one of the most important items on the todo list for the viewer, it is going to appear in the next build (likely a public one).

We are going to make significant improvements to labeling in the builds following that. Whatever part of these improvements will be coming to Radian, Viewer will get automatically on the same update schedule.

KlausDE

6,410 post(s)
#22-Jun-17 09:27

I imitated a non-GIS customer and just doubleclicked the EXE as an ordinary user. The mfd-viewer-9.0.164.4-x64.exe installed flawless on Windows 10.

As the viewer is a read-only app it doesn't touch Mfd8 map files. The file is still accessible for Mfd8.


Do you really want to ruin economy only to save the planet?

antoniocarlos

609 post(s)
#24-Jun-17 00:56

I think this is a great starting point for a universal data viewer!

It installed properly on my PC with Win 10 as well. If I open a Manifold map component, the viewer does not keep the styling or the correct layers on or off. That is the map shows the layers that must then be styled by the viewer. This takes time.

ACGT


How soon?

Dimitri


7,413 post(s)
#24-Jun-17 06:18

the viewer does not keep the styling or the correct layers on or off.

Is that a Release 8 .map or a Radian .map? Viewer is Radian so it should operate exactly the same as Radian when it come to style. Open a Release 8 .map in Radian and formatting is not preserved. If I open a Radian .map in Viewer I see all the styling as it would be.

If you have a Radian .map that Viewer opens differently than Radian, please report it.

On the plus side, since Viewer is a Radian subset, improvements in Radian within the subset automatically apply to Viewer.

As the Radian platform expands, for example, with more/improved formats or more features in support of Release 9 engineering you'll see those improvements in Viewer as well, as the platform acquires more and more features in the direction of GIS in addition to killer data engineering. For example, next week's build will include some improvements, and so on. With builds every week or two it adds up very quickly.

tjhb
10,094 post(s)
#24-Jun-17 08:22

I read Mike Pelletier's comments with interest and agree with a lot of the substance.

On the other hand, the Viewer would continue to evolve as the Manifold 9 product family evolved. Dimitri has confirmed that I think.

That means there will be judgements to be made about exactly what features should be included in the free Viewer, and which should be available only in retail editions of Radian Studio, Manifold 9, or other products (if any).

A bit of reflection has made me think that it's unrealistic--in future, but even now--for all Manifold SQL functions to be made available in the free Viewer.

It might be useful to think of the Surface Tools extrension to Manifold 8 and (to a lesser extent) the Business Tools and Geocoding Tools extensions. They were attempts to draw lines to mark off "premium" feature sets. I don't think exactly the same demarcations are likely to be best now, but perhaps similar thinking might help shape a feature set for the Viewer.

I think it would be too much to include (even) the full current set of SQL functions with the free Viewer product.

That's partly natural justice (something like that), but also based on an interpretation of what I think is one of Mike Pelletier's main points (as I read it). Namely that the inability to export data should not seem a disproportionate restriction, when the full range of Viewer capabilities is borne in mind.

Mike's example of triangulation is good. Why allow users to make a Delaunay triangulation for free, but then to export none of it? That's not going to feel like being given something, as much as it feels like being prevented from something. The restriction might feel disproportionate, in context. Better not to allow triangulation within the Viewer; if you want that, just upgrade. (After all, it costs so little.)

Here's a sketch of additional restrictions that might be applied to the free Viewer.

  • allow native Manifold SQL only (no queries using SQL syntax from other databases, although they could still be addressed in Manifold SQL)
  • limit CPU core usage to 6 (for example; still very generous)
  • omit specialist SQL functions; for example, Delaunay, Voronoi, tile curvature functions (to come), interpolation functions (to come), graph functions (Gabriel Netowk, Nearest Neighour, Shortest Path, etc, still to come), and some others [by the way these restrictions seem proportionate to disallowing scripting]
  • ignore PRAGMA directives, except for progress indicator

That's not exhaustive and not right, but something of that sort. I think a line should be drawn, partly to encourage people to invest in the paid products.

tjhb
10,094 post(s)
#24-Jun-17 09:25

When I wrote that I hadn't read the latest posts above from Dimitri and Adam.

Having read their posts I'd narrow the list down to just this (in addition to the current restrictions, including no GPGPU, no saving, no scripts).

  • limit CPU core usage to a maximum of 8 cores [not 6]*

and strike out the other suggestions I made, which are all taken care of entirely by the prevention of saving from the Viewer, and moreover would be annoying.

Besides, the demarcations would be a pain to decide and enforce, and would give the wrong impression. (The impression should always be: this is about the user and the data, not about the tool.)

[*Why limit to 8 cores? Well, it makes quite a good impression, doesn't it? Pour encourager les autres.]

adamw


10,447 post(s)
#24-Jun-17 09:42

(I was writing a reply to the previous post, mainly addressing the question of why include transforms, etc. I guess this is a shorter version of one aspect of what's in Dimitri's post, I am going to post it even though you read Dimitri's post already. We will discuss limiting the number of cores.)

The idea behind allowing to do transforms and everything else and only limit the saves / exports is that the user then can not only view data in any of the supported formats (combining layers from different data sets together in maps, applying formatting, taking care of coordinate systems, etc), *but also* try actual workflows.

Like "OK, I need to prepare a report on sales per city area, I see that this data set of points with the sales I have overlays in the map window pretty well with the base map and the set of city areas that they gave me, and I see the fields I want to sum, so how do I sum again? maybe there is a transform for that... this one looks promising, let's try it... <and some time later, hopefully> well, I guess that's the numbers I want!". And if someone needs to do such reports regularly and buys a full version because he finds the workflow easy and straightforward, all the better. It's a win-win.

Dimitri


7,413 post(s)
#24-Jun-17 12:32

limit CPU core usage

I don't like that at all. I feel badly enough about not having GPU turned on.

If somebody has more than 8 cores we want to give them the big fun of watching all of those cores light up in action. It's just a cool thing to do and it won't discourage anybody from supporting the work that goes into this if that's what they'd choose to do in any event. And somebody who has 32 or 64 cores? That's our kind of parallel maniac. :-)

Mike Pelletier

2,122 post(s)
#24-Jun-17 15:28

Agreed since showing the speed and abilities of RS is a big part of Viewer. I think Viewer should do what it does very well and the lack of save/export will provide a great incentive to purchase for those who want more than viewing.

Adam, it's great to hear that labeling and an info tool are coming to RS and Viewer. Having a convenient search tool, rather then relying on query components, should be added to that list as well. These are things that are critical to viewing data efficiently and if absent will leave people with a negative "huh" about the product.

In addition to Dimitri's example of hunting rocks in the desert, I could see a mature Viewer being good for emergency responders for use in areas of no cell/internet service if a suitable Windows 10 mobile device exists.

By the way, the installer for the .exe worked perfectly for the both RS and Viewer and I have been unable to install the .msi version of RS since about have way through the beta.

Dimitri


7,413 post(s)
#24-Jun-17 17:33

Having a convenient search tool

Ah... this is very interesting. I agree. What should such a search tool look like? For example, if you had to name the top three things it should do, what should they be?

To make it easier, what are the top three things it should be when you are looking at a drawing layer in a map? At a table?

Looking at a raster it is harder to imagine something relatively easy that should be free. Harder and paid is easier: a zoning person or a tax auditor asks "search for swimming pools" or better still, "search for swimming pools that were not there in [name an earlier image]." But for that you need machine recognition/learning. That's surprisingly accessible these days using GPU. Not coming soon to a Radian near you but eventually once 9 is out there and expanding... well, why not?

Mike Pelletier

2,122 post(s)
#25-Jun-17 15:07

Great, I like it when you agree :-) How about a Google like box with the word "search" in it to indicated a place to type in your search. Have the default behavior be "contains" not case sensitive. Maybe have it run on all tables by default but only one table if a table is open or selected in the project pane or a drawing is selected in a map tab. Maybe a way to change this with huge data. For more refined searching add the current Find tool dialgoue in Mfd 8. Leave raster searching to the experts and their SQL.

Thanks for the heads up on the eclipse!

Dimitri


7,413 post(s)
#24-Jun-17 17:46

Speaking of rocks in the desert there is something in that essay where I missed the point. It's this bit:

You might say, "OK, all that is cool but it really is a super benefit for people who have Radian," and the reply is, Yes! If all Viewer does is deliver yet more value to people who have licensed Radian it is worth doing.

That's too limited, because it ignores the multiplication effect.

All you need is one guy with Radian to publish some intensely useful data, like a project that contains map with strewn fields for known meteorites and background big images for the fields, and you can have a hundred thousand people use that project for free with each using a free copy of Viewer.

So sure, having Viewer is a benefit to that one guy with a Radian license. But it's also a real benefit to the hundred thousand people who use that project out there riding around on dry lakes looking for dark dots or trudging the Arizona or North African desert.

Which reminds me: we have to add GPS connectivity to the platform. That's mainly for 9, but, of course, once it is in the platform it can apply to everything. When you are out there hunting dark rocks on a featureless dry lake you want to see where you are on the map and have the map move based on what it hears from the GPS in your tablet.

That reminds me: everybody download the Eclipse map for Release 8 that's on the website. 21 August in the US is one of the best total eclipses ever for the US, and you want to be able to use Manifold to position yourself on the centerline. If there are patchy clouds you can use Manifold to help find a spot, repositioning yourself along a highway right up to the last moment for a break in the clouds to see totality.

danb

2,064 post(s)
#25-Jun-17 01:13

I think you have pitched it just about right. For me as a Radian user, it will be a superb way to advertise, pass prototypes and even finalised solutions to clients.

Dependent upon the level of client skill or interest, they can either simply view derived results or perhaps even mine and refine them further, with the limitation of not being able to save the modified product or export the results. This is great, if they could do the latter, what would be the point of purchasing Radian?

Sure there will be situations where the viewer provides them with all that is required (we have several people who just need a few refreshed statistics each day calculated from data updated on servers overnight), but to be fair I would suggest that these folks that are very unlikely to ever progress to a full licence anyway. What they will become however is:

1. More familiar with the sorts of things Radian can offer, hopefully stimulating more solutions.

2. Vocal about what a great product Radian is and how much it has helped them in their workflows.

One final thought is what a superb way in which to try before you buy for potential users. All that power at your fingertips and the ability to see if your workflows will be supported in a Radian environment. Perhaps along with the viewer and examples that Manifold are planning to make available, there could also be some prebuilt downloadable map files showcasing particular work areas such as lidar, image manipulation, dynamic spatial analysis etc, etc.


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

Dimitri


7,413 post(s)
#25-Jun-17 07:04

viewer provides them with all that is required [...] unlikely to ever progress to a full licence

Very true. Plus, for Viewer to provide them with all that is required that means somebody in the organization got at least one full license for authoring. If the organization really does have very many sophisticated, but view-only, queries/calculations/reports going on there's no doubt we'll get a fair share of full licenses.

An analogy that comes to mind is how GIS applications built on Manifold IMS are basically free. If you can create a GIS application that is entirely IMS based your cost per viewer is zero. But to create those applications you'll need at least one, and likely more, of Manifold 8. People don't pay for a plug-in to view GIS enabled web applications but the value of being able to create such sites is great enough for Manifold to get a fair share of selling useful tools. Same with Viewer and Radian / Release 9.

I also like the idea how having lots of Viewers will get additional benefits for the Manifold community. We'll have more localization files for more languages, for example, since if you create a localization file for Viewer that works for Radian and 9 and vice /versa.

It's also true - you can see it in this thread already, for example, with Mike's suggestion for an info tool and better search tools - that having lots of Viewers out there will naturally result in more suggestions that will help drive improved ease of use and presentation capabilities, at first in Radian and then in 9.

there could also be some prebuilt downloadable map files showcasing particular work areas such as lidar, image manipulation, dynamic spatial analysis etc, etc.

Strongly agree. For now, on the Viewer page for downloads (will go live this week, I expect...) there is only one such file, a .map with a collection of REST web servers. People can open that or add it as a nested data source to Viewer and then just double-click to open it, without having to go through the hassle of finding the various URLs and entering them in the Create Data Source dialog for a REST web server.

We should provide the Boston file as well, perhaps hosted on github where lots of people downloading a 36 GB file won't slow down access to our main servers.

That has turned out to be a factor for such stuff, as the Internet really isn't well-geared for routine exchange of files in the tens of gigabytes. I suppose we will have to add Torrent capability to the Radian platform so that people could more easily exchange very big files

jockeryl
178 post(s)
#25-Jun-17 03:40

I hope that you consider to make the viewer available in the Windows Store when it's ready for the public.

Many low cost Laptops and Tablets will be shipped with Windows 10 S, which cannot install the app using normal EXE/MSI installer.

The normal Radian/Manifold can require Windows 7/8/10 Pro, that's ok I think.

I think it passes the requirements for a direct port to be UWP compatible:

https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare

lionel

995 post(s)
#06-Aug-17 19:13

never use windows store even with windows 10 ( for ACL or permission issue even if Microsoft os need/know my credential for login ) . I hope exe/Msi/zip ll be still accessible using both method : download from webpage and windows store. But every store ( google market , itune , .....) take their fee and have their own bank system payment ( paypal with amazon , google pay /Wallet , Apple pay , ..............)

I don't think radian/manifold use tehnology only available on pro version of microsoft OS ! have you got example that show that user on microsoft has limited functionnalities on manifold/Radian compare to user that use pro Microsoft OS ? !!!

Good question are radian/manifold compatible with uwp engine ?


Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en

adamw


10,447 post(s)
#07-Aug-17 06:07

I don't think jockeryl said that Radian / Manifold requires a Pro edition of Windows. The point was that the most important product to put into Windows Store is Viewer (and Radian / Manifold can continue to be installed normally).

In terms of being UWP compatible, we did preliminary checks and we are compatible, the only sticking point is using third-party components like database clients and add-ins, for which we (a) cannot guarantee anything and need to perform further checks, and (b) may need to install more of them from the beginning to save the hassle / slightly rework how they are added to an existing installation.

KlausDE

6,410 post(s)
#07-Aug-17 08:05

Only a short digression: Are there discussions somewhere in the virtual world, if - from a users perspective - we should just ignore the attempt to establish Windows Store?

I hate the perspective that at some day google might close the door to install applications not distributed through their store and mistrust their quality management.


Do you really want to ruin economy only to save the planet?

Dimitri


7,413 post(s)
#07-Aug-17 10:18

No worries. From Microsoft's side, they don't have the ability to limit installation of applications to only those acquired through their Store (not remotely legal), and (one hopes) they have the common sense not to try. I think Microsoft knows better than anyone that if they tried to force use of their Store they would just kill off whatever depended on it. They know they have to make it attractive in and of itself.

Dimitri


7,413 post(s)
#07-Aug-17 09:23

to make the viewer available in the Windows Store when it's ready for the public.

It's ready for the public now. Open and view hundreds of formats and zillions of web data sources. For quick video tutorials, see https://www.youtube.com/channel/UCy4F7Bgf5tyHQK4PoIamF-w

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