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


9,480 post(s)
#15-Jan-21 15:35

9.0.173.2

Here is a new build.

manifold-9.0.173.2-x64.zip

SHA256: 5c8cc90ee7bf2f75105da853b30d2f9888a9493490506c584b02abafdf056a76

manifold-viewer-9.0.173.2-x64.zip

SHA256: 1163200309c9ec798a03860eb89bc5596034c1aef273fbb4b8a4c828b57bad39

This build contains improvements to registration. Next: incremental improvements to registration, improvements to geometry editing, various quality of life features.

adamw


9,480 post(s)
#15-Jan-21 15:35

Changes

There is a new registration method, thin-plate spline, which can be used with both drawings and images.

The '(no source)' caption in the Register pane has been renamed to '(current window)'.

The map window highlights selected control points.

The map window allows selecting control points using Ctrl-drag. Ctrl-drag selects all control points within the drawn box. Shift-Ctrl-drag unselects all control points within the box. The Ctrl-drag and Shift-Ctrl-drag boxes ignore labels and only use control point locations.

The map window allows selecting control points using Ctrl-click. Ctrl-click selects a clicked control point, Shift-Ctrl-click unselects. One can click either the location of a control point or the label for that control point.

The default names of control points have been changed from 'Control Point XXX' to 'P XXX'. The first control point is named 'P 1' (instead of just 'P').

The Register pane includes a toolbar with a Delete command. Before, you could delete selected control points in the control point list by using the Delete key. Now you can also click the Delete button so you don't have to worry about the keyboard focus.

Control points for a target window in the Register pane can be turned on and off. By default, all control points are turned on. Turning a control point off hides it in the map window and stops using it during the registration. Changing the location of a control point in the map window turns it back on if it was turned off.

Numeric registration no longer attempts to solve a warp when there are too few control points. Instead, it quickly fails. (Previously, the process would use one of the possible solutions, which is not desired.)

Numeric registration solves a warp exactly if possible. Previously, the process was always using a least-squares fit. This was losing some accuracy when the warp could have been solved exactly. We have extended the process to solve exactly if possible.

The Register pane has a new Saved Control Points toolbar button, which allows saving current control points. Saving control points creates a new drawing and a new table in the database of the map. The new table includes an identity field and index, a geometry field and index, as well as a name field. Control points for a target window with no locations provided are not saved. The created drawing is marked as containing control points (via the 'FieldNameRegister' property) and is selected in the Project pane.

The Register pane allows loading current control points from previously saved control points drawings using the dropdown menu for the Saved Control Points toolbar button. Records with empty geometry or with geometry other than single points are ignored. Records with empty names are ignored. Records with repeating names are ignored after the first one encountered (the choice is random). The total number of loaded control points is limited to 1024. Loaded control points are converted to the coordinate system of the map.

New query function: CoordConverterMakeWarpThinPlateSpline - Takes a line geom containing warp coordinates and returns a coordinate converter object that performs the warp.

(Fix) RTREE indexes in MAP files no longer reduce single-point geoms with XYZ data to XY in output for spatial searches. The fix does not apply to already existing indexes, but it does apply to new records inserted into such indexes.

(Fix) RTREE indexes in MAP files no longer reduce multi-point geoms which are repeats of a single coordinate to single-point geoms in output for spatial searches. The fix does not apply to already existing indexes, but it does apply to new records inserted into such indexes.

End of list.

lionel

691 post(s)
#16-Jan-21 15:34

Whan see the word warp this make me think of adobe Warp tool ( youtube) , but i think it is not the same ?!! Adobe has many handle to change the shape of text vector/glyph area/Line .

ArcGis has a really good illustration about WARP .

Manifold Documentation warp 12345678910

Changes and Additions (manifold.net)

Coord SQL Functions (manifold.net)

CoordConverterMakeWarpNumeric(<geom-from-to>, <order>): <converter>

Takes a line geom containing warp coordinates and a numeric order for the warp, returns a coordinate converter object that performs the warp. Coordinate converter objects are treated syntactically like a table, so we have to write

CALL CoordConverterMakeWarpNumeric(...)

Each branch of the line geom is interpreted to contain the source location as the first coordinate and the target location as the second coordinate. The easiest way to understand how the line geom is structured is to set up georeferencing using two or three control points and to then press Edit Query in the Register pane to see how the resulting SQL is arranged.

The numeric order is rounded to one of the following values: 1, 1.5, 2, 3.

Returns NULL if an coordinate converter object cannot be created.

CoordConverterMakeWarpTriangulation(<geom-from-to>): <converter>

Takes a line geom containing warp coordinates and returns a coordinate converter object that performs the warp. Coordinate converter objects are treated syntactically like a table, so we have to write

CALL CoordConverterMakeWarpTriangulation(...)

Each branch of the line geom is interpreted to contain the source location as the first coordinate and the target location as the second coordinate. The easiest way to understand how the line geom is structured is to set up georeferencing using two or three control points and to then press Edit Query in the Register pane to see how the resulting SQL is arranged.

Returns NULL if an coordinate converter object cannot be created.

Example: Detecting and Correcting a Wrong Projection (manifold.net)

no warp

However when reprojecting a coordinate system like Pseudo-Mercator into a significantly different system like Latitude / Longitude, the warping caused by the reprojection can distort the appearance of labels or icons in image servers like Bing Streets or Google Streets. It is therefore a good idea to use Pseudo-Mercator projection for maps that will include image server layers.

Example: Georegister a Drone Photo (manifold.net)

no warp word in html page

Example: Georegister a Vector Drawing (manifold.net)

no warp word in html page

Register Pane (manifold.net)

When we press Previewor Registerin the Register pane, Manifold uses mathematical algorithms to warp, reposition, and re-project the source component so the control points we have marked in the source window line up as best as possible with the corresponding control points in the known-good, target window.

Reproject Component (manifold.net)

The direct sub-pixel reprojection option enables 9 to compute coordinate system transformations for images to conversion accuracy even more detailed than the size of a single pixel. That is important when a single original pixel during warping / georegistration can expand to more than one pixel in the new image, or vice versa.

Reprojection Creates a New Image (manifold.net)

That is important when a single original pixel during warping / georegistration can expand to more than one pixel in the new image, or vice versa.

Sub-pixel Reprojection (manifold.net)

The better quality may be important in some use cases when a single original pixel during warping / georegistration expands to more than one pixel in the new image, or vice versa.

  • What's New in the Latest Build (manifold.net)

  • Numeric registration (order 1 through order 3) no longer attempts to solve a warp when there are too few control points. Instead, it quickly fails safe. Previously, the process would use one of the possible solutions, which is not desired.

  • Numeric registration solves a warp exactly if possible. Previously, the process used a least-squares fit. That lost some accuracy in cases when the warp could have been solved exactly. The process has been extended to achieve an exact solution whenever possible.

  • New query function: CoordConverterMakeWarpThinPlateSpline - Takes a line geom containing warp coordinates and returns a coordinate converter object that performs the warp.

Attachments:
adobe_warp.png


union

Dimitri


6,436 post(s)
#17-Jan-21 05:01

"warp" is not a technical word describing some specific industry-standard command. It is just a plain English word that is used to mean "distort, deform, alter." It's a shorter word than the usual GIS description of "rubber sheet distortion" and similar.

The problem with words like "deform" is their negative connotation implying a transmogrification from correct form. "Warp" also has a slight negative connotation in common language, but "warp" but seems to have less of that in technical settings. Words like "alter," "transform," and "reshape" are too generic and don't convey a sense of rubber-sheet deformation.

If you look at the Photoshop illustration, that's not a bad example of why "warp" is used as a word both in that setting as well as in georeferencing. Matching/distorting the linear source text to fit into a target curved red destination region is similar to georeferencing features that are linear in some source window into what is a curved region in some target window.

adamw


9,480 post(s)
#18-Jan-21 15:05

ArcGis has a really good illustration about WARP .

Yes, that's the same concept.

pslinder1
220 post(s)
#30-Jan-21 04:33

I know I am being a bit spoiled, but wondering when the next cutting edge build is due and what will be in it?

Dimitri


6,436 post(s)
#01-Feb-21 07:24

Adamw's comments are usually a good guide.

pslinder1
220 post(s)
#02-Feb-21 00:29

That is good for the what but not the when.

jsperr102 post(s)
#02-Feb-21 00:58

"Patience, young grasshopper" -- all shall be revealed in time.

Mike Pelletier


1,829 post(s)
#19-Jan-21 21:45

Wondering what people think would be the best way to handle this situation.

Often people want to register a component (for example, a survey) that has dimensions on it. Those dimensions are likely the best information (better than the control points) and so the registration process needs to keep that dimension accurate.

So the first step might be to scale the component to match the dimension, perhaps by drawing that dimension as a line in a drawing (especially once we can do that with the drawing tools that include adding scale factors for the coordinate system). Then do the final registration process to move/rotate it to a place on the Earth, while preserving the scale.

Could we get a tool that allows clicking a start and end point in the component and entering a dimension? Hit run and the component gets scaled to match.

I think this would get used enough to justify a tool, in lieu of the first step in the process described above. I think this also would need adding the move/rotate but not scale registration process to the current list of processes available.

Thoughts?

Dimitri


6,436 post(s)
#20-Jan-21 08:08

Just thinking out loud, I'd guess it ultimately depends on what you want for accuracy, and where you want to make accuracy tradeoffs, especially in the case of new data that you want to fit into existing data.

If you just want to take something from CAD or a metes and bounds description and, without regard to the precise details of other content, place it semi-manually someplace on Earth (which is what the process of scaling and then move/rotating it boils down to), that's straightforward. A scale tool only needs to provide three points, which could easily be two lines that each have a dimension, or, if X and Y scale are assumed to be the same, just two points with the distance between them. Move and rotate is likewise straightforward. I could see such things added to Manifold as part of the georegistration toolkit.

But there is more to consider if what is being semi-manually georegistered is required to correctly align with existing data.

Suppose you have a parcel map that's in some sense "official," in that it's the baseline for some tax office or central cadastral registration of real estate. It shows a bunch of parcels, with open space off to one side.

OK, now you want to add a real estate development that fills in that open space as subdivided into new parcels. You get that drawing of parcels from some CAD or other format where the dimensions of the parcel boundaries are claimed to be exact, but the format isn't in any coordinate system has has anything to do with the planet Earth. It's just a CAD drawing in abstract Euclidean, XY, space.

You want to import that CAD drawing and georegister it so that the kinked boundaries of parcels align perfectly with the corresponding kinked boundary at the edge of the baseline collection of parcels.

One side effect of the Earth being a 3D shape and the CAD drawing being flat is that when you re-project (which is what georegistration really is) that CAD drawing into any Earth based coordinate system you're almost certainly going to face a choice: either

a) The vertices that define the shape of the parcels being added will exactly align with the vertices that define the edge of the existing parcels, in which case the new parcels you add will snuggle right up to the existing ones with no unseemly overlaps or gaps, or

b) The lengths of the segments (the dimensions) marked for the line segments that define the parcels will remain exactly as specified, in which case the vertices won't match and you will end up with overlaps or gaps.

It seems to me the above are the likely best cases. If the CAD drawing is not internally consistent it could be that a regular reprojection (i.e., between known coordinate systems) would be insufficient and that the data would have to be warped in some irregular way, as done with spline transformations, for example, for the vertices to fit.

If your standard of accuracy isn't very high, then you might get away with it, with vertices aligning and, not looking at too many decimal places, the dimensions remaining the same as originally claimed. But even simple effects like the ellipsoidal flattening of the Earth are about a 1/300th effect, over 3 millimeters in a meter, or 1/3rd of a foot in a 100 foot property. Getting 1/3rd foot off in a hundred feet is grossly inaccurate for a modern survey. With a quality CAD drawing done well you might not see anything so gross, but I wouldn't be surprised the transformation process caused some discrepancies out there in the sixth or greater decimal position.

There is a somewhat related issue in traverses, where it is routine to get a traverse that does not "close" if you take the linear dimensions and angles literally. Follow the traverse directions exactly, and you don't end up exactly at the spot from which you started. ESRI has a tool for that (Manifold will sooner or later), that adjusts all the traversal dimensions and angles evenly across the entire figure to achieve a close, but doing that is changing the numbers.

You could do something analogous in this case, if it was necessary for an addition to a official standard to have to conform to that standard, at least along the edges where the addition touches the official standard.

Without knowing the specifics of demand, I'd guess (just a guess) that a simplified Affine, basically an "order 0.5" (that's humor, not a mathematical statement...) would be higher priority in cases where you want to align to existing data. After all, when you have visible vertices along the edges that are supposed to come together it's easy to click a few and get a fast and easy alignment. If the dimensions end up being slightly different from the original in the sixth decimal place, that's probably as good as you're going to get in any event given the non-spatial starting data.

Mike Pelletier


1,829 post(s)
#20-Jan-21 15:52

Good points. I'll just add that this highlights the need for the registration process to be flexible. Users will run across many different accuracy needs as well as existing data accuracy. Finding survey pins to align surveyed data is a big deal. It involves travel, decent weather, and luck that they haven't been destroyed or buried. Existing parcel mapping can vary dramatically in accuracy, especially since often it's purpose is for taxation, which generally only needs low accuracy.

Here's another use for the process we are discussing. We have some underground coal mine maps from early 1900s, that we want to align correctly because people are building homes above them. The maps have no dimensions, except for a scale bar. To align them on the landscape, the only clues are adits (exit points). These provide a rough alignment because the adits were backfilled for safety and may have been otherwise modified after the map was made. The scale becomes the best data and it may take a lot of judgment to get the best alignment.

I think it was geozap who suggested a more manual/intuitive way to initially register (scale, rotate, shift) without control points. Couldn't agree more. Yesterday, I used Mfd8 to register a 1950 survey and a 1990 highway construction plans map. The purpose was to better map parcels in the area, which are currently grossly off. Ultimately, I'll likely get some decent control points, but the survey pins are now buried in snow, up a steep slope, and a 4 hour drive away.

We created a grid of points covering our county that provides scale factor and rotation info that can be applied to ground survey data to adjust it for our coordinate system. So we just apply the factors from the closest point in the grid when drawing vectors. Having a simple way to apply these adjustments when entering them into Mfd would be great so we don't have to do it on a calculator first.

Parcel mapping is a big part of GIS work and I'd like to suggest that it is an excellent use case for Manifold to focus on for designing the software. If the software is good at parcel mapping, it will likely be good for many other similar uses.

dchall8
808 post(s)
#20-Jan-21 20:57

Dimitri said,

Without knowing the specifics of demand, I'd guess (just a guess) that...

Say what you want about ESRI and their expensive, worldwide army of marketeers/trainers, but that army is their source of supply and demand intelligence. Sustaining that army requires the annual tax of license fees, so I'm not suggesting Manifold recreate such a marketing animal, I'm just suggesting Manifold brainstorm some ideas to find answers to some of the burning questions.

Mike said,

Parcel mapping is a big part of GIS work and I'd like to suggest that it is an excellent use case for Manifold to focus on for designing the software.

As a former appraisal district and oilfield mapper, I agree that the (mundane) task of parcel mapping is a core feature for GIS to handle. Parcels can be country, state, county, parish, township, region, oblast, or whatever. But for the GIS software supplier, there are far more potential users drawing local parcel maps than there are doing Art Lembo type analysis in government and universities. The parcel element does not stop at simply outlining the parcel. Our team of appraisers collected 75 or so fields of information, many containing comma separated data within the field. I needed to be able to call on the information to present it spatially to the office and public. That always included basic, but meaningful, labeling and color coding as is necessary for any communication. However my degree in practical applications of probability and statistics leads me to the advanced features necessary for Art's large scale information analysis. I am likely the first Texas appraisal mapper to bring LiDAR into the office. I'm likely the first to calculate parcel carrying capacity for livestock using USDA land productivity surveys. The LiDAR was a huge improvement over the inaccurate contour maps used by my predecessors. The livestock calculation was a revolution in appraising farm and ranch land. These are important features which go far beyond the parcel, but the parcel is still the informational anchor for the analysis.

Dimitri


6,436 post(s)
#21-Jan-21 08:05

I'm just suggesting Manifold brainstorm some ideas to find answers to some of the burning questions.

Already there, and works great. There's absolutely no doubt on burning questions and how to support what's desired.

I apologize for being unclear. My comment was about the demand for a specific feature, specifying a distance for a given line, as a means of setting scale. Depending on the use case, there's probably an easier way to set scale. It's true that with just one person talking about that feature there's no direct evidence of demand, but hey, lots of great ideas start with just one person. Getting those ideas is a strong part of Manifold's intake system.

that army is their source of supply and demand intelligence.

ESRI's intake system is designed primarily for, and works brilliantly at, discovering how to sell GIS in quantity to organizations and how to subsequently maintain account control. That's a different goal than creating the best possible GIS for people who actually do GIS day in and day out, and it is a radically different goal than creating the best possible GIS at the lowest possible cost. There's obviously some overlap between the different goals but there's no doubt which goal ESRI's business model prioritizes.

Manifold's system prioritizes and works much better at zeroing in on specific things that make for better workflow. It's especially good at connecting great ideas that may pop up just with one person to the engineering resources that can put them into action. You can see that in action compared to the ESRI systems for georeferencing, which after decades of work are more cumbersome than Manifold's first effort in 9. And you don't see ESRI immediately improving their system in a mere two weeks, as Manifold just did, with yet more improvements in the next build.

Regarding parcels, I don't think anybody disagrees with you that parcel mapping is a core activity in GIS. That's one reason Manifold is doing a push on editing tools now, and why Manifold introduced traverses.

As you point out, synergistic effects between other Manifold capabilities, like LiDAR, which at first glance might not have anything to do with parcels, can really help make parcel work better and easier. Another example is sub-pixel coordinate transformations in rasters, which Manifold automatically does in georegistration, as well as parallelized methods like thin-plate spline, so you can try previews without fear to nudge registration as you like by placing and moving a few control points.

There are many other cases where the availability of orthogonal capabilities help out with parcel and other work. For example, yesterday I noticed that a scanned image of a paper map I was working with had a seam line in the middle where it was folded. Not a big deal, but on close examination the two former paper halves of the map were separated by a slight gap.

To do an accurate georegistration, it would have been better to use the image not as delivered, but to take the upper half and to nudge it downwards so there was no seam between upper and lower half. Easy to do, but the problem was that I'd already had placed about twenty control points in the upper half of the source image.

No problem. Save the control points to a drawing, drop the drawing into the no-seam version of the source image, select all the upper points, use shift with restrict to selection to nudge them to match the move of the upper half of the image (move one exactly and all the others move along with it), and then load control points from that adjusted drawing. Was almost quicker to do than writing that paragraph.

But anyway, back to parcels: if there's ever anything specific you need for better work with parcels, speak up. :-)

Mike Pelletier


1,829 post(s)
#24-Jan-21 22:00

I'll speak up :-) While vector editing/topology tools are obvious, better labeling is probably not so obvious. Those who view parcel maps are used to seeing lots of labels for dimensions and various other features. To present parcel info, it will be important for 9 to up its game on label control.

Importing ESRI labels and display them as they are seen in ESRI would be a good guide to what is needed first. That may just be thematically controlling rotation and label conflict control.

ranger.sean90 post(s)
#26-Jan-21 00:35

I agree.

Appreciate adding that sort of functionality and new features like numerical scale & scale bars etc. won't necessarily create a point of difference between Mfd and the likes of ESRI, but it might help consolidate what is already a superlative bit of software, and possibly help to move the average users experience forward.

Staff in the company I work for spend almost as much time creating material for print as they do manipulating the data that sits behind it. Access to better labelling tools in 9 would be a quantum leap and might (finally) allow us to dispense with licenses for ArcGIS.

dchall8
808 post(s)
#27-Jan-21 18:44

I agree with Mike and Ranger. Working with parcels is primary but so is communication of information about the parcels. The limited labels now are a starting point. Also need multi line labels with left, center, and right justification. The ability to highlight words by changing from normal to bold or different sizes within a label would be a nice boost. M8 can take information from multiple fields for use in a label, and that needs attention in M9.

At the appraisal district I used to export a KML file for Realtors, surveyors, banks, title companies, or anyone else who wanted to use it. Within M8 I had a computed field which created a label within the KML. The code to write the label exploited HTML and CSS features in Google Earth and extracted the appropriate data from M8 on it's way out in the export. When you click on a parcel in Google Earth, the "bubble" appears. Here is a sample.

Note the ability to use background and font colors as well as the ability to link out of the bubble to various websites based on information coded into the bubble.

Attachments:
Google Earth Overlay Enlarged.png

ranger.sean90 post(s)
#27-Jan-21 20:48

dchall8 said,

Working with parcels is primary but so is communication of information about the parcels.

You expressed that far better than I did.

lionel

691 post(s)
#06-Feb-21 02:27

I undertsand that manifold don't support rendering 3D even i think support can compute data that have 3D coordinate. After see the capture , i need simple confirmation :

Does Google Earth in 2021 is only available on Browser ? So no desktop version is available ( microsoft or Mac OS ) .

Does manifold 9 support preserve Y/high/elevation in drawing ? so that mean manifold 9 support import 3D file !!

Does manifold 9 support for only drawing export to KML the Y/high/elevation in drawing ?

Is there a kind of compute field functionnality in manifold 9 ?

Does manifold has already function ( Transform) that compute use Y high data ?

regard's

NB I do a script in the past for old manifold version that use compute field but don't find it using manifold forum input form search ! i find this (2008) but not what i want even close !


union

Dimitri


6,436 post(s)
#06-Feb-21 05:59

Does manifold 9 support preserve Y/high/elevation in drawing ?

Yes. See the Data Types topic as well as the many transforms and functions for working with Z values in geoms.

so that mean manifold 9 support import 3D file !!

Manifold supports importing those file types listed in the various dataports for formats and data sources, or using GDAL.

Does manifold 9 support for only drawing export to KML the Y/high/elevation in drawing ?

KML is primarily a vector format. "overlay" images can be added as described in the GroundOverlay section of the KML topic.

Is there a kind of compute field functionnality in manifold 9 ?

? Time to read the Basics chapter. :-) See the Computed Fields topic.

Does manifold has already function ( Transform) that compute use Y high data ?

I think you mean Z (height) data. Yes, there are many. See the various topics in the Transform Reference chapter, such as for Transform - Geometry.

adamw


9,480 post(s)
#19-Feb-21 15:18

I read the entire thread, will answer a bit on our current priorities here:

We agree having a separate tool to do the simple shift / scale / rotate interactively to make things line up as a form of rough registration would be great. We don't want it to alter component data, however, just adjust the coordinate system and for that we need to extend our definition of coordinate systems to allow for rotation. We will do this, but given that everything the tool will be able to do can be done with registration, just in a different way and perhaps slightly less visually (have to press preview every time after you move a control point), this currently has a lower priority than other things discussed in the thread.

Right now, we are working on vector editing. This is a big area that will always have wishlist items, but we are aiming to get most of the things that people are doing that we are currently missing before we put it down. After that we will probably move to labels / presentation (want to rework and improve the Style pane). Then we have a couple of big new things that we want to introduce, maybe we'll start introducing them in parallel with labels, we'll see.

No guarantees, everything can change, etc.

Dimitri


6,436 post(s)
#21-Jan-21 08:44

a more manual/intuitive way to initially register (scale, rotate, shift) without control points.

Generally, people want easier ways to scale, rotate and shift, so you have to look at how many clicks any proposed user interface requires, and how those clicks fall into the workflow. In all the scenarios you mention, you're not talking six digit precision but, by GIS standards, rough approximations. So I'd say we're in agreement on this bit:

A scale tool only needs to provide three points, which could easily be two lines that each have a dimension, or, if X and Y scale are assumed to be the same, just two points with the distance between them. Move and rotate is likewise straightforward. I could see such things added to Manifold as part of the georegistration toolkit.

Don't let the words "control points" force you into thinking you can only use survey pins with the system as it is.

Control points are just clicks, and you could use those clicks as nothing more than edit handles to grab a source and scale, rotate, and shift it to place it where you want.

A user interface that says "click twice and then hit Preview with the method set to Affine" is a pretty darned simple way to get scale, rotate, and shift all at once, and to show the result in a 50% preview about where you think it should go.

After that you just click in the target window to adjust one of those "handles" (I'll call them that to avoid any pressure about "control point") and hit Preview again to zero in on what you want.

Yes, sure, having a "0.5 Affine" with constrained scale, rotate, and shift (no shear), and X/Y axis scales identical would be nice. But I've done a lot just with existing 1.0 Affine and it already works really well.

Likewise, I could see decomposing a fast, all in one step command like we have now into multiple steps. Most people prefer an all-in-one transform, but I could see why you might want a multipart process, where first you click twice to set a scale, and then you do a rotate, shift using a command that does not alter scale.

Experience shows that most people do better with a combined rotate, shift than with separate rotate and shift commands, because it's hard to judge the center of rotation. So, when those are different commands people tend to do some rotation, do some shifting, adjust rotation, etc.. If you've ever tried to rotate and scale layers in Photoshop to line up with the right size to other layers you know what I mean. But hey, no reason those couldn't be separate commands as well. But I'd still wager that most people would prefer "two clicks and done" to iterative use of three commands. :-)

We created a grid of points covering our county that provides scale factor and rotation info that can be applied to ground survey data to adjust it for our coordinate system. So we just apply the factors from the closest point in the grid when drawing vectors. Having a simple way to apply these adjustments when entering them into Mfd would be great so we don't have to do it on a calculator first.

You can use Local Scale for that. Whenever you bring a raster or vector into Manifold even if the thing is not georegistered you can assign it to be in, say, Hotine Oblique Mercator centered on 0, 0 with a spherical base (use any linear coordinate system where the ellipsoid is a sphere). You can now use local scales to scale it to be the "real" size it's supposed to be.

If I understand your grid of points system, the X and Y scale factors could be applied automatically to the projection for your ground survey data, using a bit of SQL, completely avoiding the need to manually assign them. I suppose you could assign rotations and shifts as well, using the parameter boxes for the Hotine projection.

Just saying, there are ways to automate this that once you work them out the first time can be used over and over in similar situations. I'm not saying those are a replacement for manual, interactive means, just saying there's a rich toolset to use in different situations that might pop up in parcel mapping.

Mike Pelletier


1,829 post(s)
#22-Jan-21 04:03

Agree with everything your saying and yes I get the idea behind control points of varying accuracy.

I'll just add that allowing steps during the registration process allows keeping the error where it should be. So if you have survey plat with poor control (river bank, old road, etc.), you can get the scaling and rotation correct, then play with the location from there. If you just know the scale (from perhaps a scale bar) you can get that right and work from there. Maybe one good control point is all you have. Bottom line is the flexibility Mfd tends to offer with its tools is very very helpful.

It would be cool if Mfd could apply to a traverse scaling and angle factors on the fly based on the location within the coordinate system. I imagine it could be done but elevation plays into the scaling so it gets complicated. Surveyors I think need to change these factors for every line, but we just approximate it given the lower accuracy we are shooting for. This of course is way down the list.

Its most exciting to see registration tools growing and the coming vector editing!!!

Mike Pelletier


1,829 post(s)
#22-Jan-21 14:53

Here's a clipped down version of the grid that I was referring to.

Attachments:
survey factors.mxb

adamw


9,480 post(s)
#19-Feb-21 14:56

I am late to the thread and didn't read it in full yet, so I will just quickly answer something and proceed to reading all other posts:

Could we get a tool that allows clicking a start and end point in the component and entering a dimension? Hit run and the component gets scaled to match.

'order 1, affine' does this as it stands. You place two source control points and two corresponding target control points at the desired distance from each other, then register (or preview) and the result is shifted + scaled + rotated accordingly.

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