Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.175.5
adamw


9,773 post(s)
#10-Nov-21 17:16

9.0.175.5

manifold-9.0.175.5-x64.zip

SHA256: a382381c08109b656ba39441ac56054b00dc135202639bdef8c6be59121b3362

manifold-viewer-9.0.175.5-x64.zip

SHA256: b4a0ccca7aedfe38a74d772a00e7f25e22db63e2fc8b3af55efaac004d10622e

sql4arc-9.0.175.5-x64.zip

SHA256: dced7a2a51fde8fc58285f951c46a2618136f278b8b53d6508d42226a6ad7995

This build extends formatting options for field values and allows applying formatting to fields shown in tables. Next builds will automatically carry this formatting to labels.

adamw


9,773 post(s)
#10-Nov-21 17:20

Changes

The table window allows changing the alignment of field values using the Align Left / Align Center / Align Right commands in the context menu for a field.

The default size for binary fields in a table window is forced to be constant (was adjusting to the system font).

The table window allows changing the format of field values using the Style command in the field context menu. The command is disabled for text fields (this will quite likely change in the future). Fields of all other types support it. The command invokes a different dialog depending on the field type:

  • binary: select style from the list of available styles, specify language
  • boolean: select style
  • date: select a standard style or compose a custom style from parts, specify language
  • geom: select style, specify language
  • number: select style, specify the number of digits / decimals, specify language
  • tile: select style, specify language
  • uuid: select style
  • vector: select style, specify the number of digits / decimals, specify language

All styles and style parts show what kind of output they are producing in the dialog. The language is specified using an editable dropdown box which allows either typing the desired value directly or picking it from several default choices (neutral language + languages for available localizations).

There are two cases where the table window ignores field styles:

Editing a cell always uses the default style. Otherwise it is too easy to lose data. For example, suppose that a numeric field is set to show two decimal digits. This shows 3.14159 as '3.14'. If we start editing the value and the edit box opens with '3.14', pressing Enter will accept '3.14' and change the value from 3.14159 to 3.14. This is unwanted. To prevent that, when we start editing the value, the edit box opens with '3.14159', showing all available digits.

Filtering records by right-clicking a cell and using the commands in the context menu always reports the value of the clicked cell using the default style. Similarly to editing, applying a style would miscommunicate what the filter is going to do.

(Fix) The table window no longer hides the euro sign and several other Unicode characters not recognized as printable in the default CRT locale.

The Add (Field / Index / Constraint) and Add Identity commands in the Schema dialog focus the last added schema item.

The Schema dialog includes a filter box to filter schema items using their name. Filtering by name automatically disables the Add (Field / Index / Constraint) and Add Identity commands to prevent newly added items from being immediately hidden due to not passing the filter. Editing an existing item and changing its name lets the item stay visible even if the new name no longer matches the filter.

The Schema dialog includes a filter button with a dropdown menu to filter schema items using their type (All / Fields / Indexes / Constraints). Filtering by type automatically disables the Add (Field / Index / Constraint) and Add Identity commands for items that will not pass the filter. (So, for example, if you set the filter to only show fields, you can still add new fields, but you cannot add indexes and constraints until you change the filter.)

The Move to Top / Move Up / Move Down / Move to Bottom commands in the Schema dialog are removed. (These commands could only reorder new schema items and such reordering only made sense for computed fields referencing each other. We felt this was a case where the commands were trying to help those who already knew what they were doing at the cost of confusing everybody else, so we removed them. In the future we will also be able to handle computed fields coming in an arbitrary order, provided there are no circular references.)

New query function: StringDateTime. The function takes a string and attempts to parse it into a date time value according to the specified language.

New query function: Random. The function produces a random floating-point value between 0 and 1, with 1 excluded.

New query function: RandomInt. The function takes an integer limit and produces a random integer value between 0 and limit-1.

New query functions: RandomRef / RandomIntRef. The functions produce random values similarly to Random / RandomInt, but take an extra argument of an arbitrary type to use as a dependency.

New query function: RandomHash. The function takes an arbitrary value, composes its 64-bit hash using FNV1a, and turns that hash into a pseudo-random floating-point value between 0 and 1, with 1 excluded. (The purpose of this function is to produce a value that is both uniformly random across the domain of argument values, and coincides for calls where the argument value is exactly the same.)

New query function: RandomHashInt. The function takes an arbitrary value for the hash and an integer limit, composes the 64-bit hash using FNV1a, and turns that hash into a pseudo-random integer value between 0 and limit-1.

New query function: DataHash. The function takes an arbitrary value and composes its 32-bit hash using FNV1a.

New query function: StringFormatBinary. The function formats an arbitrary value using one of the following formats:

  • b (default) = <varbinary> -- with the type name
  • B = <varbinary, XXX b> -- with the number of bytes

New query function: StringFormatGeom. The function formats a geometry value using one of the following formats:

  • b = <geom>
  • B = <geom, XXX b> -- with the number of bytes
  • t (default) = <geom, line> -- with the type of geometry value
  • T = <geom, line, 200 c / 3> -- with the number of coordinates and the number of branches after a slash; if the number of branches is 1, it is not shown

The StringFormatGeom query function detects geoms with Z values and reports them as 'areaz', 'linez', 'pointz'.

New query function: StringFormatTile. The function formats a tile value using one of the following formats:

  • b = <tile>
  • B = <tile, XXX b> -- with the number of bytes
  • t (default) = <tile, 100 x 100 x 3> -- with the width and height and the number of channels; if the number of channels is 1, it is not shown
  • T = <tile, 100 x 100, float64x3> -- with the width and height and the pixel type that includes the number of channels

New query function: StringFormat. The function formats an arbitrary value according to its type. (GEOMWKB values are currently reported as binary to avoid conversion, similarly to previous builds. We will change this to report GEOMWKB values as geometry in the future. Also, the number of bytes reported in the 'B' format by StringFormat / StringFormatBinary may differ from the number of bytes reported in the 'B' format by StringFormatGeom / StringFormatTile. The former two functions report the number of bytes in the value as it is stored in a MAP file, with some compression already applied. The latter two functions report the number of bytes in the same value expanded to RAM, with no compression.)

The StringFormatNumber query function now uses language-specific decimal separator for the default format.

The StringFormatVector query function now uses language-specific list separator for the default format.

(Fix) The GDB dataport marks computed fields for length and area so that they do not prevent copy and paste of tables into a MAP and get converted to non-computed fields instead.

The Clip transform automatically removes records with NULL geometry when producing a new table.

(Fix) The LAS dataport no longer sometimes returns incomplete data for a spatial search.

Error reports produced by the GDB dataport and dataports for databases like SQL Server are extended to cite the names of relevant fields and indexes.

End of list.

Mike Pelletier


1,947 post(s)
#10-Nov-21 21:10

Another step closer. Thanks!

What would be a nice addition is styles for showing lat/long in all its many configurations. Really though it needs to be editable in those configurations. So if you have data in degree minutes and seconds, we don't have to manually convert it to decimal degrees to enter the point. This was always annoying in 8.

Also, the computed field section of the documentation has an example for adding fields for lat and long. It fails when I try it. Perhaps it is using outdated SQL? It would be great to get this working.

I tried creating a drawing with lat/long projection and added a point. The coordinate tab shows values that don't match the lat/long degrees. What is the format here?

Dimitri


6,852 post(s)
#11-Nov-21 04:17

Neither of the following is about 175.5, so perhaps it would be better to launch a new thread to discuss them:

Also, the computed field section of the documentation has an example for adding fields for lat and long.

Do you mean the section titled "Computed Field Equivalents to Release 8 Intrinsic Fields" ? Those expressions work perfectly for me. I just tried them. Did you use a data type of float64 when you created the computed field for those? If you describe all details of what data you're using and the exact workflow we can find the issue.

I tried creating a drawing with lat/long projection and added a point. The coordinate tab shows values that don't match the lat/long degrees. What is the format here?

I just tried that as well, and it works perfectly. Here's what I did:

1. Create a new map with one layer, Bing streets background.

2. Create a new drawing that uses lat/lon. Drag and drop into the map.

3. Pan/zoom the map to a location where you know, for sure, the latitudes and longitudes.

4. Create a point.

5. Alt-click that point, and in the Info pane click the coordinates tab: it shows the longitude, latitude coordinates using decimal degrees.

Mike Pelletier


1,947 post(s)
#11-Nov-21 14:21

Well I was on the subject of lat longs :-) Okay so the SQL works where you pulled it from. Further down there is Queries that Add Computed Fields. I added it to the attached project and it fails. It looks outdated.

Still, using your procedure, I'm getting roughly -350 long and 126 lat for a point that should be -106 long and 38 lat.

Attachments:
latlong.map

yves61
320 post(s)
#11-Nov-21 16:40

Mike, I have looked into your latlong.map.

a) your query makes reference to a "Drawing" drawing in the CoordConverterMake clause that does not appear as a component.

b)The Default Lat/lon CoordSystem and [latlong from T1] (T1) drawing have different CoordSystem definition , although the name used is the same : "Lat/Lon".

> ? ComponentCoordSystem([LatLong from T1])

nvarchar: { "Axes": "XYH", "Base": "World Geodetic 1984 (WGS84)", "Eccentricity": 0.08181919084262149, "LocalScaleX": 0.30480060960121924, "LocalScaleY": 0.30480060960121924, "MajorAxis": 6378137, "Name": "Latitude \/ Longitude", "System": "Latitude \/ Longitude", "Unit": "Degree", "UnitLatLon": true, "UnitScale": 1, "UnitShort": "deg" }

**************

> ? CoordSystemDefaultLatLon()

nvarchar: { "Name": "Latitude \/ Longitude", "System": "Latitude \/ Longitude", "Base": "World Geodetic 1984 (WGS84)", "Axes": "XYH", "MajorAxis": 6378137, "Eccentricity": 0.08181919084262149, "Unit": "Degree", "UnitLatLon": true, "UnitScale": 1, "UnitShort": "deg" }

---------------------------------------------------------------------------------------

[latlong from T1] drawing CoordSystem has a LocalScale X and LocalSclae Y of 0.30480060960121924 that does not appear in the default Lat/Lon CoordSystem.

---------------------------------------------------------------------------------------

So to me it looks like VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 0) needs a correction with LocalScaleX and LocalScaleY values that CoordConverterMake() ignores ???

But, I may be wrong as well !

Mike Pelletier


1,947 post(s)
#11-Nov-21 17:27

Argh, your right about the reference and the scaling. That scaling must have crept in from importing some other layer and then I turned it into a favorite. Thanks for opening my eyes!

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