Recently in another thread that I didn’t want to hijack, Dimitri said words to the effect that we make more work for ourselves when we try to make spreadsheets act as databases and vice versa. True.

Some time back, Art suggested classifications of GIS practitioners that resonated with me. They are:

Sub 2 million record people where most of us live.

The other extreme of big data where multiple machines must be involved through technologies such as Hadoop (and I suppose you could add folks who play with big iron here as well). Not as many GIS folks here, I assume, as I don’t know of many.

And then there is the hole in between where V9 plays well. A new market? Who knows how many?

Finally we have Manifold’s own website suggesting that V8 is the classic GIS perfect for beginners. I couldn’t agree more, which I suppose, makes me a many year beginner😊.

Now for the confusion part. Is V9 a whole new product (as has been suggested many times) or is it an incremental product release as the naming convention suggests? If the former, great! I can happily go on using V8 for years to come with my small data in my blissfully spreadsheety way. When I need to work on larger datasets as I have needed to do recently, I’ll have V9 at the ready.

But what if it’s the latter? From where I sit, it feels like this is more likely. I doubt seriously that “Version 9” was an accidental name. If so, that would be an uncharacteristically large break with convention on Manifold’s part.

So I guess the $64,000 question is, “How long before the V8 training wheels come off?”

Hi Ben,

My thoughts on 9 is that it should replace 8 and that the reason it hasn't for many people is that it is missing a few key things. Ver. 8 just doesn't cut it for sizable image processing and it also has the annoying unreadable curved label problem. Ver. 9 lacks good labeling, pixel level image processing, web mapping, GPS tracking, some key vector editing tools, a simple scale bar (not a big deal except for occasional users), and the GUI has some weird flow process that take awhile to remember.

However, 9 is great on many things other than just speed and I've switched from 8 largely. 9's project file is a better beast: fast, can't easily overload, and interconnects with other .map files. Cartography graphics are better, minus the labeling issue (a BIG issue). SQL is a big change but better. What vector tools exist are really great. Clip for example. Georeferencing tools are much better. GUI works pretty well on a smallish, say 12", laptop. Better connections to streaming data. Some of the smaller (to users, not necessarily to programmers) and obvious missing items are rather agonizing slow in coming. Lastly, the speed thing means you can play around with different scenarios much easier. That makes things more fun.

Glad I've dived in. :-)

some key vector editing tools,

What are the top five such tools you feel it lacks?

Some of the smaller (to users, not necessarily to programmers) and obvious missing items

Everything that goes into Manifold gets prioritized by user demands. Users call the shots, not programmers. There's even a well-known guide for how to influence the process most effectively.

Never assume that something you want is an "obvious" priority for other people. 9 has a very wide range of applications, with a very diverse community of interests, so it always is better to express yourself than to assume other people will send in priorities that are the same as yours.

Some general advice for anybody reading this thread:

If you follow the advice in that guide to help steer priorities, and the product keeps getting steered in other directions, that indicates that those other directions were a greater priority for more users. Don't take it personally.

Instead, go back and re-read the guide and pay close attention to the advice offered for people who want something that is not being requested by many others. For example, providing specifics on what you want makes it easier for something to get implemented.

Thinking in terms of details of how you want something to look and to function in 9 also helps get around the problem of not having learned 9 and thus asking for things that are already in there. It's hard to talk specific details without having good familiarity with 9.

Also make sure to take advantage of basic advice for getting your way. Don't send suggestions using mail packages that insert images into html mail, so when the message arrives the plain text result is something incomprehensible, like "This is what I want" followed by blank space. Use plain text mail, as the advice recommends.

Ver. 9 lacks good labeling, pixel level image processing, web mapping, GPS tracking, some key vector editing tools, a simple scale bar (not a big deal except for occasional users), and the GUI has some weird flow process that take awhile to remember.

Thanks for a great, concise list. Many of the above things are in the plans for changes and additions, several are in the works right now.

I understand that we have been talking about some of these improvements for a long time. The time it takes for these improvements to appear is big for two reasons.

First, in each case we want to significantly extend and improve what we had in 8. In each case doing a feature justice is significantly more difficult than for things that we already re-added, because 9 demands more from the feature than 8 did. (An easy example is shared overlap control for multiple label layers. 8 was rendering a map using a single thread, bottom-up, so resolving overlaps between multiple layers was trivial. When you render a label from layer #3 out of 10, the labels for layers #4-10 have already been placed and checking whether a new label from layer #3 overlaps any of the already placed labels is easy. However, 9 is rendering a map using multiple threads. So when you render a label from layer #3, some labels for layers #4-10 might have been already placed and others might have not. Coordinating which of the conflicting labels should win the overlap contest is much more involved, particularly because the process needs to be reasonably fast.)

Second, we have many other features that compete with these ones for development resources. And while we do have things that we agree we had before and that we agree we need to re-add, we do not want to pause development across other directions until we re-add everything that we used to have. Doing so would be much less efficient than working both on "old" and "new" things in parallel. Particularly because sometimes "new" things clear roadblocks for "old" ones that we used to have before and want to re-add. (An easy example here is the read-only database server that we added recently. Your list of missing features includes web mapping, the server is a big step forward to that.)

Now, I'd like to give a quick synopsis for each item on your list, both to roughly communicate where we currently are and to ask a couple of quick clarifying questions:

• good labeling - we think we mostly understand what is missing, we are working on readability for curved labels / more control over placement / overlaps,
• pixel level image processing - mostly understand as well, planning to allow writing per-pixel expressions for transforms and do per-pixel selections,
• web mapping - mostly understand, planning to add it, the approach will be different from 8, but better,
• GPS tracking - we view this as a relatively small thing, basically: center map on current GPS location / track a line while GPS is working, is that about correct or are we talking about something bigger?
• some key vector editing tools - here we think we are mostly done, plan to add some snap modes / allow direct editing of traverse commands, perhaps add undo in several places, is there anything else?
• simple scale bar - planning to add this to layouts, but there is a bigger item here in that north arrow / scale bar / legends should perhaps work in map window as well - we are thinking about implementing them there, too, but slightly differently from how they appear in layouts, eg, for legends in a map window, you won't be able to format / reposition individual items (just set up some general format), but you will be able to turn layers on and off, to collapse and expand layer groups, the list of layers will scroll, etc - is that OK if legends and other things that I named will work slightly differently between maps and layouts?
• GUI has some weird flow process(es) that take awhile to remember - we would like to know the details.

Thanks again for your post, it was very helpful.

Thanks Adam. It's always great when your able to share a bit about plans and the why behind them, such as the multiple thread issue with labeling. Also, good and fast labeling is not the norm with GIS software, so the challenge is appreciated. Also, definitely get the phrase "anything worth doing, is worth doing right".

Your understanding of the issues seems right on target and here's a few additional thoughts:

• labels - maps with a few labels as multi-line labels look classy, so it would be great if that can be part of the automatic placement algorithm.
• GPS tracking - agreed its not a big issue, but really nice when you need it.
• vector editing wish list - move multiple objects at once, move shared vertex, better traverse data entering (direct editing, rounding, scale/rotation factors for the location, bigger font size for readability and cursor placement), some undos, snap to boundary and add vertex in that object at same time, nudge vertex with arrow keys, and ideally an interactive (drag handle and place to type specific amount) way to rotate/scale objects.
• Yes, it seems fine to have map legends/etc. work differently than layouts. For map making, I much prefer in the layout, but I suppose the in map version is needed for web mapping?
• Layer blending tools - these can make spectacular results fairly easily and now that Arc/QGIS have it, I think Mfd really needs it. Also, style dialog would be good for place for undos.

I would love to see the legend in 9 work like 8. I personally make mapimages and do screen captures for clients to paste that in presentations a lot. Not being able to have the legend dynamically change when you turn a layer on and off in the map in is very cumbersome, let alone only have the legend available in a layout. If it means having to set up separate layouts and manually build legends for each layout because you are only using certain layers, that is a lot of time consumed. The other option is to use M8 but that means exporting the layers and losing the style that I set up in 9, ultimately causing me to do most of the work twice just for the visual of the legend.

Not having view bots and the ability to run various data tabulations on datasets without having to build your own SQL really slows those of us who don't program in SQL. Along with this problem is a simple but very much missed features, giving the number of selected records in addition to the total records. I use this all of the time when consulting with clients on the phone.

@ radiowebst your post manages to touch on most of my main bugbears with 9. I still do all my mapping in M8 as it has all the bits that I need and also F6 to make an image of a map (perhaps with a dynamic legend included) but as you say this causes quite a bit of double handling.

I do however love 9 for analytics and use it for all my analysis these days. I sometimes struggle with the new syntax (particularly for grid/image manipulation), but the speed and power is wonderful for productivity and experimentation.

It is however IMO sorely missing the features you mention such as ViewBots, selected record count etc. but I feel sure that they will appear sooner or later.

I would recommend submitting some suggestions, though it can sometimes feel like you are posting into a black hole. Having said this it can also be very rewarding and Manifold tech have been particularly agile with some of the LiDAR suggestions that I have put in over the last year or so which is excellent and one of the things that distinguishes Manifold from the pack.

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

Not having view bots and the ability to run various data tabulations on datasets without having to build your own SQL really slows those of us who don't program in SQL.

Why would it slow you down? After all, you still have to write the expression you want the viewbot to use, and if the SQL expression is about the same, it's not a big issue.

I was a very staunch advocate for viewbots when the idea first came up and I still like them, but most uses of viewbots are extremely simple. Take a look at the operators list for viewbots and 99% of them are such simple expressions in SQL you'd almost not call it "SQL."

Show the maximum for the price field:

SELECT Max(price) FROM titles;

Show the sum of all sales for all titles:

SELECT Sum(sales) FROM titles;

Go down the list of operators for viewbots and it's pretty much all the same as the above, just varying the SQL function you use.

Data tabulations you can do with viewbots are usually very simple SQL expressions, the sort you can learn in a few minutes, like the above. Why not spend a few minutes to learn how to do those? It opens the door to a very wide range of capabilities that provide a whole lot more than Viewbots, like all those hundreds of convenient functions in 9 that aren't available as viewbot operators in 8.

I still like viewbots for compact, packaged displays for interactive use, of course. But using SQL to do data tabulations and other analytics on tables is also very easy, goes a long way, and is worth doing. You only need to learn a tiny amount of SQL to get a whole lot of use out of it.

You missed the part about not knowing how to program in SQL :-( If I go down that road and try, it's usually at a time when I am busy trying to use the program to get a task or two done and move on to doing the other things I also have to accomplish for the client.

Please understand that with Manifold at this price point, is a tool for lot of users buy it to do some tasks and move on to the rest of their job/tasks. Having to effectively learn SQL or writing a script is like asking a person to learn a new language. The transform tool bar (and all the functions in it), view bots, number of selected records and the other stuff I am whining about helps a medium type user do great things without having to be a programmer or have to take the time out to learn that type of skill when GIS is not the only thing they do.

I realize those are simple queries to a lot of you, but where to do it and how to in M9 would be a great topic for another video please. Syntax and such usually trips me up and at the worst time when I have deadlines to meet, so I grumble and export to do it in M8.

I honestly love the video series you have been doing. The short format is usually on task and teaches me the topic and lets me apply it quickly. Please keep them coming, maybe have descriptions of the task in the manual linking to them in the relative topics. It's a wonderful teaching method.

At this website:https://www.artlembo.com/sql4arc

I have a bunch of free videos, and also a standard dataset you can use.

There are also links to my training class in how to use SQL in Manifold 9.. This is a full training class that takes you from the very beginning all the way to writing more sophisticated SQL.

And finally, I have continued my How do I book series and have one on SQL with Manifold 9. This steps through all the classic GIS operations using SQL.

It would be great if the user could add custom queries to the transform or select tabs. They are just SQL queries with graphical elements for inputs. If having written a query you could then add it to transform (or a custom transform tab) and then MF would automatically generate the input boxes from the input definitions in the query. Users could then also share these queries. Complex queries are then easily shared and implemented across projects.

Viewbots in 8 come into their own when the scope is set to "selection". Interactively selecting with "select invert" (we use 8's select modes a lot) in a map or drawing is a super way of refining / editing area object selections comprising "districts", for example. Reference to the relevant ViewBot is just the best for fine tuning this (for us) bread and butter objective.

Inclusion of analogues to 8's "Business Tools" - "districting" and "optimal routes / drivetime zones" would make transitioning from 8 more enticing. We deploy them often.

I don't know if Mike would include remembering focus in using the GUI to work with multiple components as a weird flow process, but I find it often hard to remember. It is covered in the documentation examples but can be hard to remember in the workflow. For example, I had trouble getting georegistration to work consistently for a long time until I realized I had to note on paper the steps and on each step whether the source or target window (identified by component) had the focus. More recently, I was advising a colleague and his grad students who had purchased copies of M9 and had carefully read the Getting Started, some of the basics, and some of the videos. I realized how unaware they still were of the importance of focus in the workflow of many tasks, even as simple as focusing on a table vs. on a drawing it produces.

This workflow focus issue does not need a new feature in the GUI since shifting focus between multiple components, once understood and internalized, works so well to make the workflow fast and easy. What is needed is an explicit short discussion of it at the beginning of Getting Started to give context for when they later read "with the focus on . . ."

Everything that goes into Manifold gets prioritized by user demands. Users call the shots, not programmers.

This is what surprises me about the latest release concentrating entirely on networking. I was sorely disappointed with it. Has there been any discussion in the forum about networking?

As suggestions go to Manifold, it is completely a one-way street. We have no visibility to what has been suggested so that we might try to influence the priorities.

I had trouble getting georegistration to work consistently for a long time until I realized I had to note on paper the steps...

Have you seen how they do georegistration in Arc? It seems to be dead simple. It's completely interactive. You match one point and the image zooms to that part of the world. Locate a second point to get orientation and size, and it might be finished. Move the interactive map around to see if you need to tune it up and put in a third point as a final adjustment.

Given the 2 months waiting time, I was hopping that that big feature under work was raster pixel-level image selection/transformations, so I was also disappointed to see that the feature was not that. But I am a single user, and I understand companies with several users really need the functionality added in the last build and also the future addition of read-write usage of linked data. So I can't complain.

I was hopping that that big feature under work was raster pixel-level image selection/transformations

Why, given that doing raster math on tiles is effectively doing it on pixels as well? Look at all the many examples of transforming images in the user manual... those are all transforming the values in pixels.

It's true that there's no simple per-pixel selection, but there's an endless amount of raster math you can do on images anyway, like the examples adamw gave here. If you make your queries slightly more complex, you can do endless selects and conditionals as well.

If there's something specific you need to do, bring it up in the forum so other users can show you how to do it now. For example, Sloots provided powerful examples to the question of how to do classic map algebra on rasters in 9 here and here.

Also, consider sending in a Suggestion if there's something you want that cannot be done in 9 today. Other people are doing that, so if there's something important to you that you want, don't hesitate to suggest it.

the latest release concentrating entirely on networking. I was sorely disappointed with it. Has there been any discussion in the forum about networking?

? Just looked through the latest release and I don't see anything there about networking. It's all about the new Manifold Server and advancements in ArcGIS REST servers, TIFF format, etc.

Server is about multiuser sharing of the same data and easier archiving and access to frequently used layers. It's a great way for individual users on a one machine to share the same layers into multiple different sessions at the same time. It's also key technology that is the foundation for upcoming major features like the web server and multiuser editing.

We have no visibility to what has been suggested so that we might try to influence the priorities.

If you want to influence priorities, there's a well-known guide for how to do that. If you want to influence priorities, follow that guide.

Note from the guide that talk in the forum doesn't steer priorities, so I'm puzzled that you would raise that despite the explicit discussion in the guide about that. See the FAQ discussion for Why are not suggestions on the Georeference forum monitored? What counts are priorities set by people speaking their minds directly and privately without peer pressure.

Have you seen how they do georegistration in Arc?

Yes. A good example is the ArcUser article on how to georeference a drone photo that is cited in the Manifold example that does the same thing in 9, providing an apples to apples comparison. Based on what that article describes, the 9 way is much easier. For example, 9 doesn't require you to specify coordinate systems in advance or to set up a definition query (!).

It seems to be dead simple.

The key words are "seems to be". It's only simple if you don't get into all the details that go into the process. Anybody who doubts that should read the ArcUser article cited above.

ArcGIS Pro can require significantly different workflow depending on whether you are georeferencing a raster image, a vector drawing, or a CAD data set. In each such case there are many messy details which all must be done right or the thing doesn't work.

For example, from the ArcUser article:

In the Contents pane, select EV_001.JPG, click the Imagery tab, and click Georeference. Notice the Georeferencing window in the upper-right corner. On the far left of the Georeference ribbon, click the Set SRS (for spatial reference system) button. Confirm that the Map XY coordinate system is NAD 1983 UTM Zone 10N.

Click Transformation and set the transformation from GCS WGS 1984 to WGS 1984 (ITRF00) TO NAD 1983. Click OK to apply and save again.

Get Ready to Georeference

In the map, right-click the Drone 4 Image Outline layer and choose Zoom to layer. Write down the scale visible in the lower-left corner.

Calculate two-thirds of that scale value (for example, if the scale at Zoom to layer is 3,000, then change the scale to 2,000).

On the Georeference ribbon, click Fit to Display.

That's seriously Rube Goldberg. It's not just "click two points and everything moves around into place, " and that's just a small part of the relatively simple raster image workflow. The vector drawing and CAD workflow is different and harder to get right.

The Manifold workflow, in contrast, is much simpler and it works the same way to georeference anything to anything: Open up two windows and click to mark equivalent control points in each. Click Register. Done. Works every time.

If the match is already so close that two or three points would do the trick in Esri, then two or three points will do the trick in 9 as well. Georeference to anything, including web served layers, maps, and so on. No need to specify coordinate systems or do manual calculations or any of the other Rube Goldberg details Esri requires.

Unlike the Esri process that has different workflow for rasters and vectors, the exact same Manifold process works for everything: raster images, vector drawings, CAD drawings without any coordinate system and so on. You only need to learn one, simple way of doing it, and that one simple way always works.

If you want to do visual overlays to see what a proposed use of control points will do, you can do that with a preview, just one click of the Preview button.

By the way,the use of two different windows, as Manifold does, showing a preview in the "known good" window if you want, makes the user interface much simpler. Using the same window to show both the item being georeferenced as well as the "known good" item leads to more complicated interfaces. That's why Esri ends up with lots of special case "note this detail and that detail..." work you have to do and to keep in mind.

When using one window, you also need a way to show common control points without them getting in the way of each other, and a way to mark control points where you know sometimes it's in one layer and other times it's in another. You also don't get the ability to independently pan and zoom windows even in the middle of marking control points, so that you can get whatever view works better for you in either the item being georeferenced or the known-good item.

Manifold's interface is simpler and easier: you just pop open the item to be georeferenced, pop open the known-good reference, mark your control points in the two windows, press the Register button and the system handles all the messy details of coordinate systems, scale factors, and such for you when it does the georeferencing.

In my Neanderthal view, servers and networks are synonymous. At the same time, neither one is as important to making maps as having the tools to make maps. And when you say it is key technology for upcoming features, I do recall a few discussions about web serving. But seriously! Is Manifold 9 ready to be shown in a browser? Are you ready to show the world how behind it is with basic features? Sure having the fastest database engine is nice, but without all the GIS tools, it is just taking up space on the hard drive. It reminds me of happily using my Macintosh 128 and watching IBM PC users wishing they had that one more piece of hardware allowing them to print or attach a mouse.

Peer pressure? Does someone need to make a TicTok challenge to build custom scale bars in ArcGIS before Manifold feels the user pressure to do it? How many keystrokes have been posted trying to put pressure on basic tools? Peer pressure clearly doesn't work in this forum. Has nobody submitted a suggestion to make scale bars? We can't know the answer to that. I think a better use of the forum is to beat ideas around until an evolved concept forms as to the feature. You developers can work out the details to the approach. But when the ideas are submitted and kept secret, then feature development is in the hands of people who might not have the same vision as the users. You guys know the features necessary to have a fully functioning GIS system. We don't need to tell you that a map is not a map until it looks like a map. Someone is ALWAYS going to look for the legend, scale, and north arrow. And they are going to be peed off if they can't find all three. And if you are the one showing them the map, then you are the unprofessional. How long ago was the Radian speed machine released to the public? One might wonder what is holding you back?

Georegistration: If we are reading this forum, then we understand how a fine manual can become so bogged down in describing how to perform button clicking as to make the FM indecipherable. That's how the easiest GIS system in the world comes complete with a 5,000 page manual. Reading about georegistration is one thing, but watching it being done is quite another. If you watch this video you will see how easy it is to georeference a simple jpeg (no coordinate system) in Arc. The impressive thing to me is that it is interactive. In Manifold it is a batch process. With Arc you can see the improvements with each additional control point. In Manifold you don't know whether you've done enough or, perhaps, over done it with control points until you hit the Register button.

Regarding features selected for development and why 9 does not have the features you consider to be basic, the answer is simple: what's a basic need and what's an unimportant extra varies depending on who you ask. This gets amplified by the fact that we are talking about GIS, an area where products naturally have thousands and tens of thousands of features. I am not saying that scale bars, for example, aren't a basic need. I am saying that if we did scale bars, we wouldn't have done, say, styles for table fields, and we'd be talking about why we don't have the ability to customize the appearance of table values.

It is impossible to implement everything. So we pick and choose what to implement and in what order based on our honest idea of what will be best for the product as it is used by the entire community. We will get to scale bars, too. When we will get to them, we will make them as good or better than in other products. The feedback on this forum and elsewhere helps us understand how to do that. We are grateful for it.

Regarding georegistration, what specifically you think should be improved in the current approach in 9? What is unclear or what is lacking?

Let's talk about the Arc video.

This involves some detailed discussion, since the discussion covers the details Esri is glossing over in the video but which in the real world of doing real life georeferencing are the big difference between easy and tedious.

If you watch this videoyou will see how easy it is to georeference a simple jpeg (no coordinate system) in Arc. The impressive thing to me is that it is interactive. In Manifold it is a batch process. With Arc you can see the improvements with each additional control point. In Manifold you don't know whether you've done enough or, perhaps, over done it with control points until you hit the Register button.

The Esri video is a good example of how cramming everything into one window makes it harder. Using two windows, a "from" window and a "to" window (to use Esri's nomenclature), makes it a lot easier. For example:

With Arc you can see the improvements with each additional control point.

Ah, no you can't, because with Arc the "from" thing you're georeferencing hides the "to" thing below. The more control points you add, the harder it is to add them. In the real world, good georeferencing rarely can be done with only three control points. Esri admits that in their video, where they add many more control points and the narrator comments "see how much better that is?" Well, you can't actually see how much better it is because the "from" thing hides what's below.

Esri also skips over the increasingly tedious process of adding control points, where for each one you have to turn the layers off and on so that where you place control points in the upper layer doesn't hide where you need to place control points in the lower layer. That's really clumsy and annoying.

The impressive thing to me is that it is interactive. In Manifold it is a batch process.

In both Arc and Manifold the process is interactive. The key work in georeferencing is placing control points. The ability to do that rapidly and accurately with the fewest motions is golden.

Arc makes that difficult because overlaying the "from" thing on the "to" layer makes the process of adding control points clumsy and tedious. That's precisely why Esri's video skipped over the tedious process of adding seven or eight additional control points. If you had to add 40 control points, as are often required to do a good job of georeferencing historic maps, like the Elliot Map of Gettysburg, you'd go nuts with the Esri approach.

Manifold makes it easy because with two windows, one for the "from" and one for the "to" you can see both layers all the time. You can easily add control points to the "from" layer without having to simultaneously hide that layer, pan / zoom into a view that's better for the "to" layer, and add a control point in the "to" layer.

If you do a lot of real world georeferencing, there are a few things you learn you need for faster and easier workflow. Esri makes those key things harder, while 9 makes them easier:

First, what are convenient views in "from" layers in terms of panning and zooming aren't usually the convenient views in "to" layers. If you have to pan and zoom back and forth from what's best for the "from" layer to what's best for the "to" layer every danged time you add a control point, that very rapidly becomes annoying. That's how it's done in Arc and that becomes really annoying after the first ten or so control points. With 9 you can leave the "to" window zoomed and panned however it is convenient while you choose and mark control points in the "from" window, and vice versa. That's really useful when georeferencing to locations that are view-dependent. For example, several of the control points in the Elliott Map georeferencing project take advantage of locations in the "to" layer that are seen as a result of hill-shaded terrain elevation, such as relics of ruins of walls. Whether those are seen or not seen well depends a lot on the zoom level. You have to zoom out to see they are there, and then you zoom in to the cloud of terrain pixels to place the control point in the middle of what you saw zoomed out.

Second, it usually is faster and more convenient to add all the control points you plan on using in the "from" layer, and then add the equivalent control points in the "to" layer. That's just faster workflow because it allows you to rapidly click, click, click to place control points. You can't do that with Arc, because Arc requires you to do each from-to pair at the same time.

Third, you can do a way more efficient job of picking what you want to use for control points when you can see both "from" and "to" layers at the same time. Then it's immediately obvious what features are distinctive and visible in each, so you can rapidly and with confidence click, click, click on features that are common and good to use for control points. You can't do that with Arc.

Esri's video hides much of that from you by picking an example where the author did the tedious parts ahead of time or where he hid the tedious parts by editing them out of the video. For example, looking at the starting JPEG, how do you know what features in there are also shown distinctively with good detail in the "to" destination? You don't know, because you don't see the "to" destination, but still you have to pick that first point to click in the "from" layer on faith that when you rubber band to the "to" layer you'll find something as distinctive. The author of the video clearly tried that out in advance, so he knew to click the point of land extending out into the water.

But if you try that in real life you'll see it's incredibly annoying and tedious to try to choose sensible control points to click in the "from" layer without knowing whether there will be equivalent control point locations in the "to" layer. And knowing what will work in advance is part of doing interactive georeferencing quickly, easily and with high quality.

A good example is the Elliott Map of Gettysburg that's used as an example in the Manifold web site. That's a real-world example using around 50 points that's easy to do in Manifold but which take many times longer in Arc and would have you tearing your hair out in frustration at the inconvenience of how Arc does it. The inconvenience comes from having to do everything in one window: you can't see what control points do because the "from" layer hides the "to" reference, and not being able to see both "from" and "to" layers in two different windows at the same time makes it far, far harder to pick candidate control points.

In the case of the Elliott Map that latter bit is the key to successful georeferencing: if you can simultaneously see the "from" Elliott Map scan and the "to" target layers, you can quickly pick out features in common, such as houses shown on the Elliott Map that still exist and are visible in aerial photos. But if you can't see both at the same time, it's way too hit and miss to try to find equivalent locations, and for the ones you can find it's too hard to pick from them which are better quality than others.

With Arc you can see the improvements with each additional control point. In Manifold you don't know whether you've done enough or, perhaps, over done it with control points until you hit the Register button.

Not so. You can see that in the Manifold georeferencing videos, where you interactively can see what the control points do by clicking Preview. You don't have to hit the Register button.

In Manifold you click the Preview button and you get a great view of how the control points you've set up will work, and that Preview is much better than what you get with Arc, because with Arc you cannot see the improvements with each additional control point, since the "from" thing hides the "to" reference below it. Manifold previews don't hide what's below since you can use partial opacity and you can use the slider interactively to compare the georeferenced preview to the reference layer. You can also change the georeferencing algorithm (affine, etc) to see what that does. It's a far more effective interactive user interface if you want to see how additional control points or georeferencing methods change things.

It's also a plus to click Preview to see a Preview, because you don't want to make the mistake Esri does of covering your work with control points in the "to" layer all the time.

If you want to make an apples to apples comparison, choose an Esri video that shows the entire process. The video cited doesn't do that. Instead, it skips over real-world details that make it harder:

* It skips the setup of the initial JPEG. If you bring in a JPEG that genuinely has no coordinate system it often ends up off the African coast in the 0,0 location. Here, they've picked an example using MD state plane where it ends up on land and not too far from where you can pan the underlying map to a first "to" location easily. They also choose an example where there's a named feature they can pan and zoom to without the hair-tearing frustration of finding something equivalent that isn't in the lookup database, like you usually have to do with georeferencing of drone photos. That's a big cheat.

* It skips the examination of the proposed "to" layer to pick out a viable control point to start the process, so that when you first click in the "from" layer you know that you've clicked on something that's also distinct in the "to" layer.

* It also skips the review of the "to" layer for the subsequent control points, to know what's visible in the "from" layer is also distinct in the "to" layer. For example, the author knew in advance the road intersection he chose in the "from" layer isn't covered by cloud or trees or is otherwise poorly visible in the "to" layer.

* It skips the tedium of adding seven or eight more control points, that part being edited out of the video to just show the situation after they've been placed. In real life, the back and forth of turning layers off and on and so on for each control point pair while you're in the middle of clicking it gets really annoying.

Unfortunately, Esri does not provide the source data they used so that somebody can independently do a full version of the video that showed all the steps you'd do in real life as they have to be done. If you did that video, and then also did an equivalent video in 9, you'd see how it's much easier in 9.

If anybody wants to contribute links to the data Esri used, that would be a fun video to do to compare.

Ah, and last but not least, where's the video that shows the georeferencing process to be used if instead of georeferencing a JPEG you'd georeference a shapefile that's in an unknown coordinate system? How about georeferencing a JPEG or a shapefile to a vector layer? Those are different processes, which require you to learn a different way depending on what you're using for "from" and "to" layers.

Found a newer pdf of NOAA Chart - 12233_Public https://www.charts.noaa.gov/PDFs/12233.pdf

Here is my example of an 1884 railroad map made in NY by some engineer for a St.Louis railroad long defunct of a sleepy Arkansas hamlet of a municipality. The image on the left was a mosaic'd scanned From map, with the current construction layer that was necessary as 4 point georef wasn't going to cut it. The Right is the To/georef'd map. If I couldn't save or load collections of points to then modify, *iteratively, organically* , there would be less hair.

This is a powerful addition to Mfd9 and does need some workflow adjustments, but it is fine for the time being as priorities get adjusted with each dev.cycle.

Attachments:
StPaul Georeference.png

In my opinion Dimitri that is an unassailably persuasive post--to anyone who reads it (which is a pleasure), and who does perhaps 1/10th of the same homework you have done. Cicero would be dead chuffed.

However--I can't help adding:

Without having tried the ESRI interface out (so, zero homework, just listening and thought on my part), it seems that two massive improvements to the ESRI interface would be (1) if there were variable transparency between the "from" and "to" layers, as well as possible quick flicking of their priority, and (2) if "reveal" sliders could be added to the combined window, one vertical, one horizontal, to show "from" and "to" differentially.

Then, that there is good a chance that Manifold might combine what people really like about the ESRI interface (maybe not frequent users but only video-watchers, I don't know!) with what is clearly better about the Manifold interface--producing a single window that did really everything.

If Manifold did that, then as a second (later) step, perhaps it could also show a realtime morph of the source (subject) layer to the target layer. Much as Manifold does now with Transform previews--this time with adjustable transparency (and as always, in blue). (That should be a toggle button.)

That would be really cool. But I appreciate that it might partly compromise some of the inherent advantages which Dimitri sees in using separate windows.

We had a slightly different idea which tries to combine the benefits of the two approaches (with a single window and with two windows): here.

tries to combine the benefits of the two approaches (with a single window and with two windows)

I'm not a big fan of the split screen approach. It just moves the problem from someone having to know that they should click on the window they want to use, to having to know to click on the tab or other control for the part of the split screen they want to use.

You also end up creating a new window interface just for georeferencing that is different from how windows work otherwise... more to learn, and less likely to be learned by someone who doesn't know that in Windows you click on the window you want to work on.

That is a very standard Windows idea, not a Manifold idea, that if your application has undocked windows you click on the one that you want to use and to which you want to apply commands like menu choices and such.

That is a fundamental part of PhotoShop and pretty much every other graphics editor out there. It's also a very fundamental part of Windows: in a desktop with many open windows, click on the one you want to use.

For example, if you have three windows with Notepad sessions open, click on the one you want your keyboarding to apply to. That's exactly the same with Manifold. It's one of the basic ideas that makes a GUI that allows multiple open windows to be very efficient and useful.

If somebody is saying that with many undocked windows they sometimes lose track of which one is active, I can see an argument for adding a Tools-Option to more emphatically highlight the active window.

But that's something to consider with care, because Microsoft has spent a huge amount of money and many years to evolve the current system for showing which window is the active one with many undocked windows. Manifold now uses the standard Windows way of showing which window is active. Changing how that is done would make Manifold different from millions of other applications, so it's not something to do casually.

It's the same with tabs to show which tab is active. Manifold uses Windows defaults for stuff like that, so that presumably people who use Windows will be able to leverage their familiarity with Windows in Manifold.

perhaps it could also show a realtime morph of the source (subject) layer to the target layer. Much as Manifold does now with Transform previews--this time with adjustable transparency (and as always, in blue). (That should be a toggle button.)

Transform previews don't show a real-time morph. They don't do a preview as you change various options and enter different values in the transform template boxes. If they did, they'd show a bewildering range of previews that were not what you wanted all the way up to when you finally picked all options and set the values for what you wanted. Instead, the Transform pane allows you to set up the template as you want and then when you press Preview it does the preview.

The argument against real-time morph preview in georeferencing is similar, because usually the efficient way to enter control points is not the order you'd use if you want to avoid seeing bizarrely distorted real-time morphs. Consider the Elliott map as an example (Visit the Gallery page, press Ctrl-F to find Elliott).

The fastest, easiest, least-error prone way to do a good georeferencing of that map is to first open the scan in a window so you can pan and zoom around to get familiar with it, and to open the destination map (containing many layers, like Bing, Google or OSM street map or satellite layers, terrain elevation layers, layers of vector points of interest from Civil War hobbyist web sites, etc) in a window so you can do the same.

After reviewing both the scan and the destination to see what locations are clearly visible in each, you start entering control points by panning and zooming to a starting location, like in the upper left corner, and adding five or six at a time in both scan and destination working in generally the same area. That reduces pans and zooms to a minimum and helps you stay oriented to the context of where you're working.

But if you do that, a real-time morph would start producing wildly distorted results because the georegistration is done using a small clump of points in a small region of the scan. It stays wildly distorted far into the process.

If you want the real-time morph to fall more or less into shape and then start getting better, you've got to add control points that are far from each other, for example, in the middle and then in the four corners. That involves much bigger pans and zooms and it's easier to lose context and make errors, like confusing road intersections in the grid of roads in the town of Gettysburg.

You also end up with control points in the list where the items in the list are not close to each other, and that makes it harder and more error-prone to find the right one when you go back to edit them, as is often done in such projects. In contrast, when you enter points more systematically they tend to be grouped in order. That makes it easier to use the default naming by iterated number, instead of having to take the time to name each control point so you more easily can find it in a list where control points in the list aren't near each other.

The other thing about real-time morphs is that as fast as Manifold is, they still take some time and the calculations involved in georeferencing really big layers with many control points are demanding enough that they would interfere with the instantaeous response of the user interface. That's annoying when you're placing control points and definitely want instantaneous response to panning, zooming, and every click you make.

I do think there is a use case for real-time morphs showing a partially transparent scan above a reference layer, and that's when the scan is basically already georeferenced in reasonably close way and you want to adjust it in an informal way, like some of the distort tools in PhotoShop. For example you could click to grab a part of the layer and drag it, like a rubber sheet, to warp it in the direction of the drag. That definitely would be useful, but, as the experience with PhotoShop shows, it would be primarily useful in cases of relatively small data.

If you've ever tried to open a 20 GB image in PhotoShop you know it can't really handle big images. That's the price PhotoShop pays for having some of the tools that it does, that they only can work interactively with relatively small data. Such drag-to-warp tools are useless if you click and drag and it takes tens of seconds for there to be a response to your mouse motion.

Manifold is very fast, fast enough to create a simplified abstraction on the fly, so perhaps such tools could work with a simplified, smaller abstraction and then only when you're happy with the proposed warp would you click a "Do it" button and the equivalent warp would get applied to the full-sized data set.

The other problem with such drag-to-warp tools is that they tend to not be as accurate or as efficient as setting many control points, because warping algorithms based on informal mouse moves don't usually provide as good results as good georegistration algorithms based on precise control point matching. After all, if you can see features that are in common well enough to line them up with a drag-to-warp mouse motion, you can click on them to mark control points, and probably more accurately. If you actually try many different examples of georefeferencing, the drag-to-warp user interfaces actually end up taking longer for all the tinker time corrections you end up doing.

Is Manifold 9 ready to be shown in a browser?

Sure is. There are many examples in the Gallery page. There is a spectacular range of GIS capabilities applied in 9 to create those displays, including many styling capabilities, and even a north arrow, for those that want such. It's pretty easy in 9 to create incredibly striking and memorable displays that convey complex data in an easy to understand way.

You guys know the features necessary to have a fully functioning GIS system. We don't need to tell you that a map is not a map until it looks like a map. Someone is ALWAYS going to look for the legend, scale, and north arrow.

It's easy to do legends, scale bars, and north arrows in 9. See, for example, the Legends topic. If you search in this forum (enter scalebar in the search box in the above right) you'll find plenty of hits, along with commentary like this:

in M9 scalebars and noth arrows are doable with only a few clicks mor than in M8, but they can be styled more individually.

For North arrows, there are topics that show plenty of examples of North arrows, as well as plenty of compass rose examples shown in the forum here. Some links:

https://georeference.org/forum/t158087.16#158101

https://georeference.org/forum/t158087.16#158128

https://georeference.org/forum/t158087.16#158115

https://manifold.net/doc/mfd9/images/tp_rotated_views01_36.png

https://manifold.net/doc/mfd9/images/tp_rotated_views01_48.png

https://manifold.net/doc/mfd9/images/tp_rotated_views01_21a.png

When it comes to getting your way in terms of advocacy you can't beat using the advice in the guide. Other people are doing that, and it is a big mistake to think that those other people agree with you and are asking for what you want instead of what they want. Keep in mind that other people may have very different opinions from you. GIS is a really big tent, as they say.

A good example of that is your implication that a map doesn't look like a map, that it is unprofessional, if it doesn't include a north arrow. Many people would agree with you in that, but many other people don't agree with that at all.

You can see how that's the case but noting that by an overwhelming margin, most maps these days do not have north arrows. By a probably million to one margin, most maps these days are those served by Google maps and Bing. Neither Google nor Microsoft show north arrows on their display. Neither does OSM, for that matter. Why? Because the darned near universal standard these days is "north up." I suppose there are some examples out there of webservers that show north arrows , but unless you go searching for it in a car navigation application or such, what you get by way of web maps, especially for PCs, are pretty much universally displays with no north arrow.

For that matter, if you enter "New York" into your google browser on your Android phone, what you get for the map doesn't have a legend or scalebar either. I mention that because for about four billion people in the world, if not more, a "map" is what Google and Bing and such show them. If you want to go out on a limb and say what Google is showing isn't worth showing on the web because it doesn't show a legend, scalebar, or north arrow, well, there are a few billion people in the world who would disagree.

I'm not saying that because billions of people find the maps Google provides very useful despite them not having a legend or north arrow (both google and bing for PCs have a scale bar), that it's not a good idea to have such things. I think it is a good idea, which is why it's so easy to do legends in Manifold and why you can very quickly add a north arrow as well. I think that even though in my personal work I don't use them much.

I personally almost never use north arrows because all my displays are "north up." I do that because a) most data comes in projections that are north up, b) I use pseudo Mercator by default since that's what all the background layers I like to use are in, and c) by default people expect what they're looking at to be north up and I like to cater to their prejudices.

But there are times when a north arrow fits the bill, like when you want to show a display that instantly explains why the "Eye of the Sahara" is called that, and there it's nice to have a north arrow. Or, when I do a design for a garden or for a real estate project for a friend, where it's often convenient to show a house with rectangular rooms in an orientation where the walls are aligned to horizontal and vertical. There you need a north arrow to show how the house or garden fits into a context. In such cases I'll grab a north arrow from my project that has a collection of them and toss it into the map.

But such cases are rare compared to when I'll create a display that's north up, and I'll consciously do so because I know the people who are going to be looking at it might also be looking at north up displays they get from Google and Bing on the web.

I also generally don't use scale bars, except in dimensioning for CAD projects, where I use them all the time. But for those my tastes are simple. Anybody who has more elaborate tastes can create a bunch of fancier ones, save them into a project and then add the ones they want to the projects they use.

If you want to use north arrows and scale bars in your projects, I recommend you take that approach. Create the custom ones you want to use if you don't like simple ones, and then recycle them.

As for a different process for creating north arrows or scale bars, I can see why people who use them a lot might want a quick "click on a menu" approach to toss in some defaults. But I assure you that's not remotely a top priority for many people, at least not compared to the many other things people think are important enough to spend a few minutes to suggest. I think that's because many people who use them have learned how to do them in 9 and given that they have a solution that's good enough for what they do, other things are a higher priority for them.

Just saying, if you don't like the way people do legends, scale bars, and north arrows in 9 today, don't hesitate to send in a suggestion that says how you would like it to be done. Just keep it technical and say how you would like it to work. Have faith in the value of your insights and tastes, which will be respected. But also keep in mind that a fair process that respects your tastes and opinions is going to give other people's opinions the same respect it gives yours.

I don't know if Mike would include remembering focus in using the GUI to work with multiple components as a weird flow process, but I find it often hard to remember.

We agree this needs more attention.

Generally, the problem seems to be that you are trying to do something with a wrong window. Correct? (Not that there are just too many windows to work with, because most operations use just one window and maybe one pane, it's just registration that uses two windows.) So we should make it more obvious which window you are currently working with.

Would it help if we (a) emphasized the border or caption of the focused component window to make it stand out more, and perhaps (b) put the caption of the focused component window into the application title?

Would it help if we (a) emphasized the border or caption of the focused component window to make it stand out more, and perhaps (b) put the caption of the focused component window into the application title?

(a) might help a little, but the problem for me is mainly what you say, the two window thing in a highly visual interactive task that, in my case, I don't use more than one or two times a week.* Focus is not too hard to see (via highlighted tabs) with two windows/panes if one is docked down but if one is undocked (usually needed to use screen space better) it is hard to see. If the undocked pane has a single drawing, one can click on it with the default cursor to give it the focus, but that leads to forgetting that the georeferencing cursor might be on. If the undocked pane has a map, I still have the problem unless there is a way I could undock a layer I don't know about. The solution, of course, is to make the use of shift-C and shift-space automatic but that still requires being aware of 1 focus, 2 the cursor, and 3 the register pane. 3 is the big problem because it tries to be consistent with the approach of the transform pane working with two components. There, both (a) and (b) come in (though just needed for Register). On (b), "(current window)" should show the caption of the focused component window and indicate focus status. Also helpful (just for registration) it should be in a color that also appears as the border of the window it refers to. Also helpful would be to have the border of whichever window has focus wider or dotted or some way to indicate it has focus. I hope this is clear, and someone will let me know if I am missing something helpful already implemented.

* shifting to the Arc vs. M9 comparison on georeferencing, my philosophy is that the software easiest to use is the program one usually uses. Like so many of you, I usually make a product for other people to own and use and can't afford to buy Esri software. Arc is difficult for me to use since I don't use it much. As a social scientist, I am mainly working in vector, so now, with M9's GDB data source and being retired and no longer teaching GIS in classes, I don't need Arc stuff. No time for ancient and future history here, but were I a much younger scientist, I would need to learn to work much better with big data and R. On the first, M9 would be key but I would have to get much better at SQL. R spatial is important because so much of science is done with R. I would love to have some of the proficiency Michael Sumner (mdsumner) has, but even as he says in his sporadic but wonderful hypertidy.org blog R's strange history requires a lot of ongoing work.

Thanks.

I get what you are saying. The approach with two windows also has some drawbacks, we agree. We think the approach with a single window has much more significant drawbacks (#1 - constantly having to switch between two different places in the window when placing a source-target control point pair, inescapable), but we agree using two windows also comes with some costs.

Maybe we could rework the process of registration so that we get the benefits of both approaches. Imagine this:

You open a window with a component you want to register. You press a Register button in the toolbar. This splits the window into two parts vertically. The left part of the window is for the component you are registering = the one you started with. The right part is for the component you are registering to = currently empty (or maybe it starts showing a world map from Bing or Google). You drag a component you want to register to from the Project pane into the right part. You can pan and zoom the left and right parts independently. You can place control points in each part. The Register pane shows a common list of control points. You can Preview the result of the registration, that result will show on the left. After you are satisfied with what you are getting, you can Register.

Pros: two independent viewports, with no switching between windows. Cons: because left and right parts are forced not to overlap (which is good for placing control points clearly), working with a small screen might be difficult.

What do you think? We could do something like that in the future.

What takes a lot of time when doing a georeference is searching for target control points, zooming to them, panning etc. What would benefit users really a lot is adding a "suggest target position of control point and zoom there", as I described in this post https://georeference.org/forum/t159079.29#159095

By suggesting control points is how well known photogrammetry software such as Pix4d and Reality Capture tackle the need of fast placing control points to dozens of images. So, if manifold believes improvement of georegistration is a priority, I think that's the first thing to add. Also, it is so simple to add I suppose.

Agreed. It would be nice if Mfd could pan/zoom to calculated points on the To window as soon as it has enough information to be within reason. The other thing that can slow down the process is having to change control point names to match, so this should be avoided to the extent possible in whatever process. I think the process works great as long as you don't try and use points in the To window before putting them in the From window. In the past, I didn't do this and it got frustrating but I can't recall why. Perhaps this should be more strongly recommended in the workflow, but I get the desire to use existing To control points with a new From component. Also, would be nice to be able to name the component to be created in the Register pane rather than renaming it in the Project Pane afterwards.

I think the process works great as long as you don't try and use points in the To window before putting them in the From window. In the past, I didn't do this and it got frustrating but I can't recall why. Perhaps this should be more strongly recommended in the workflow,

Well, the recommended workflow already repeats the simple "source first, target second" workflow many times. You can see that by taking a quick look at the Georegistration topic, which is a very short, nicely illustrated topic.

The Georegistration topic right at the very beginning tells people to mark control points in the source window and then to mark corresponding control points in the target window. It even repeats that advice twice in the first three paragraphs:

Georegister an image or drawing:

1. Open the source (to be georegistered) and target (known good) components.
2. With the focus on the source window, choose Edit Control Points in the Cursor Mode button, and then click in the window to mark distinctive features with control points. Pan and zoom the view as desired to make it easy to click precisely on a desired spot.
3. In the target window, choose Edit Control Points, and then in the Register pane choose the source component as the subject.
4. In the target window, click to mark features analogous to those control points that were marked in the source window. Pan and zoom as desired to make clicking easy.
5. With the focus on the target window, if a preview is desired, press Preview to see how georegistration will happen.
6. Press Register to register the source component.

Beginning users will do the above process in a simple way. For example, beginners tend to mark all the control points they will use in the source window, and then they will switch to the target window and mark all corresponding control points in the same order. That is simple and reliable workflow.

That's pretty clear and repeated twice: mark your control points in the source window and then switch to the target window and mark corresponding control points there. Simple and reliable workflow.

The topic continues with a paragraph that describes how experienced users tend to use a more advanced workflow of switching back and forth between source window and target window. It follows that discussion of how more experienced users work with the comment:

None of the above is rocket science, but it does require reading the Register pane topic to learn how to use various capabilities that make life easier.

After that, the topic for a third time repeats the advice to place control points in the source window first and then to place them in the target window:

Georegistration is simple: we place control points on distinctive features in the component to be georegistered, and then we place control points on those same distinctive features in a known-good component.

Following all that, the "source first, target second" advice is repeated yet again, for a fourth time, in a step by step illustrated example.

Nowhere in the topic does it advise people to pop open the target window and start marking control points there first. The advice is always to mark control points in the source window first and then to place them in the target window.

If somebody ignores all that, how could you more strongly recommend that workflow? I suppose you could put a blue arrow pointing at the "here is simple and reliable workflow for beginners" paragraph, but I don't think that will solve the fundamental problem.

I think the fundamental problem is, paradoxically, the simplicity of the procedure. Once people read about it, they tend to think "Oh, that's easy" and so later on when they use the feature that they might have read about months ago they don't bother refreshing their recollection by skimming the Georegistration topic. They just have at it and do it backwards.

That they can try to do it backwards is because the very simple interface for beginners is also the same simple interface that provides more advanced features for experienced users. That's a good thing, because orthogonal user interfaces result in much more efficient learning and operation of sophisticated software that has many capabilities.

By suggesting control points is how well known photogrammetry software such as Pix4d and Reality Capture tackle the need of fast placing control points to dozens of images.

If you look at the details of how georeferencing works in Pix4d and Reality Capture work, you'll see that they still require you to enter what in effect are control points, they just do it in different parts of the workflow, and they require you to do it in a more labor intensive way. They depend on using GCPs, which are brutally labor intensive, maybe a thousand times more costly than click, click, clicking the way Manifold does it.

For example, here's a quote from the Pix4d user manual:

Pix4Dmapper can process images without geolocation. When images have no geolocation, Pix4Dmapper needs additional information to locate, scale and orient correctly the model. Ground Control Points (Step 1. Before Starting a Project > 4. Getting GCPs on the field or through other sources (optional but recommended)) will place the model at the correct location, scale and orient it. If no GCPs are used, then the scale (How to scale a project) and orientation (How to orient a project) constraints can be used.

That's followed by a warning:

Warning: If neither GCPs nor constraints are used, the final results have no scale, orientation and absolute position information. Therefore, they cannot be used for measurements, overlay and comparison with previous results. Besides, they may produce an inverted 3D model in the rayCloud.

OK, so you have to have Ground Control Points (or get into the purely manual and messy process of scaling and orienting). For those who haven't worked with Pix4D, a "Ground Control Point" is a location of known coordinates in the area of interest where you physically place a black and white rectangular placard on the terrain that is to be photographed. That's right: it's not just a click in an image, you have to go out into the field and place a rectangular sign on the terrain. If you didn't do that before flying the drone to take photos, you don't have GCPs.

Respectfully, I think it's wildly incorrect to suggest that it is easier workflow to go out into the field and to trek over terrain that is to be photographed to place black and white placards throughout the ground that is to be photographed, using, as the Pix4d documentation says: "It is recommended to use at least 5 GCPs, each of which is identified in 5 images" (!)

If you don't use GCPs, Pix4d requires GPS information built into the image that the camera or external GPS logger provided. In other words, no free lunch. They get around the hard part by requiring the image to be basically georeferenced from the start, either by photographing GCPs or by embedding GPS information into it.

Reality Capture is the same. It uses the GCPs to georeference the image in a basic way and then it has a variety of features you can use to manually adjust it. Their "suggestion lines" don't work if you haven't already aligned the images using GCPs and other features. See, for example, this article. where they depend on 11 ground control points physically placed in the terrain that were"marked and measured by land surveyors."

The "suggestion lines" that Reality Capture shows end up being extremely complex workflow. I invite anybody who thinks otherwise to read the above article and to try to decode the workflow it discusses. And none of that works without the prior steps of placing GCPs and otherwise manually aligning the images.

Respectfully, if anybody thinks that having to send surveyors out into the field to measure and place GCP placards on the ground before acquiring the imagery is easier than the way Manifold does it, I strongly disagree.

The bottom line is that "it would be great if the software could place all the control points for me" is not a realistic proposition given the current state of the art, and not even if you are willing to spend $100,000 per seat. If the software could do that, you wouldn't need to do any georeferencing in the first place.

There are possibilities in that direction when georeferencing rasters to other rasters where both images are already in similar form and where you've already done some manual setup. You can use AI to do feature extraction for features that are visible in each and then pattern match to try to find features in common.

So far, such work in addition to being extremely expensive to do (many, expensive, training models are required) is highly unreliable (the models don't work as well as you'd like for georeferencing), since the features matched usually are very different from scene to scene that is to be georeferenced. In most cases, people find it much more efficient to mark source and target control points than to spend hundreds of thousands of dollars to get georeferencing that 80% of the time has to be redone manually anyway.

In many cases, there's no AI that will help. For example, georeferencing the Elliott map a human can see a cross mark with the name of a farm and know that's something to match to a building in a modern photograph of the Gettysburg battlefield, but that's not something a pattern-matching AI could do, at least not one programmed specifically to georeference the Elliott map.

You can see how inaccurate AI-assisted feature extraction can be by looking at the Microsoft-created buildings footprints data shown at the end of the Example: Import GeoJSON File topic in the Release 9 manual. Microsoft has plenty of money and spent lots of it on the state of the art AI they used to get building footprints, yet the result is junk. If you used buildings as control points as are used in the various georeferencing examples in the manual, but in an automated process, you'd end up with inaccurate results.

As for AI-assisted vector to raster or vector to vector georeferencing, that's so far a field where there is no significant progress in doing even very high priced and very low quality results.

I agree it would be nice if the software could automatically georeference anything to anything for you without the need to enter control points, but, alas, for the time being that is not something that is an option.

I note also that being able to pan/zoom automatically to where the next control point should go is basically the same task: to know where the next control point should go, the software has to be able to automatically do the georeferencing for you. But if it can show you where the next point should go, it could just put it there itself and move on to do the rest of the georeferencing.

A related feature is indicating where georeferencing may not be as accurate, which is what the Errors option in the Register pane does. More experienced users can use the Errors report to know where they might want to place more control points for the method they are using. But that's different than the software saying where to put the next control point.

Another great post, with homework (though this time, you could safely have lost a few paragraphs IMHO).

Now as to the software guessing where good control points might be:

Forget AI, for now.

Let's imagine Laplacian filters passed over the image to be registered, in at least two orthogononal directions.

At "collision" points between their "peaks", we offer candidate control points. (With snap.)

Simple, and done.

(However I don't think this needs to be done, at all. I am just joining in. Maybe we shoukd close the conversation, unless someone can say why it matters.)

The suggestion is about something significantly simpler - given N pairs of control points and a registration suggested by them, when the user places a new source control point, automatically place the corresponding target control point (at the location where the source would end up if the registration was done using just N existing pairs). This provides the user with a reasonable default for the target control point which can then be adjusted. The idea is that letting the software place the target control point with the user then adjusting its position is faster and less prone to errors than placing it manually.

I like this idea. Yes, this should be quite easy to do. If you already have three control points with the target and the source, you already have the formula established for an affine transformation. Once you place the fourth point in the source window, you can use the affine transformation to place the target point in a spot where it should go based upon the transformation parameters.

In fact, if you have two points, you can use the similarity transformation once you place the third point in the source window. I’m not sure if this is appropriate for the triangulation method, but for the simple affine, similarity, and polynomial methods that should be an interesting way to help the user along.

When using triangulation method, another method (maybe affine) could be used just for automatic prediction of control points positions.

One approach could be to automatically (or better when the user asks for that) place a target control point, and then let the user adjust it. The other is to just pan and zoom to the target points predicted position (when the user asks for that), and show a temporary crosshair there. In the 1st case, there should be a clear indication on the GUI that the point is automatically placed and not by the user.

I think it would make the placing of control points easier on the way to Register. However, for me personally, it would be important to retain placing control points in Register. I'm doing more geogistration currently so I'm internalizing my cheat sheet steps quickly. There there are also the issues Dimitri raised, particularly

I'm not a big fan of the split screen approach. It just moves the problem from someone having to know that they should click on the window they want to use, to having to know to click on the tab or other control for the part of the split screen they want to use.

You also end up creating a new window interface just for georeferencing that is different from how windows work otherwise... more to learn, and less likely to be learned by someone who doesn't know that in Windows you click on the window you want to work on.

However on that at least on my windows the different appearance of the active window is not very apparent so I still have to look at the tabs. The active window problem comes up for me most often in my cheat sheet step getting to be able to do the preview (and would be the case even with the split window process):

• and then keeping focus on the [component providing coords] go over to the Register pane and click preview

I was one of those people on that thread lamenting missing features in 9 from 8. Dimitri just replied with a very interesting post on how yout can connect M8 to a M9 file:

If you want to work with both 8 and 9 there are ways to do that without saving and reading intermediate formats. See, for example, the Example: Connect to Manifold from Release 8example topic and the notes at the end. You can connect from 9 to 8 or from 8 to 9 via ODBC.

I ll test and post capturescreen to confirm that odbc support all type of data. So edit raster vector datetime should work without to do a map conversion (mapv8 <->mapv9)?

union, doc , APIand most important deepl & keyboard shortcut

I ll test and post capturescreen to confirm that odbc support all type of data. So edit raster vector datetime should work without to do a map conversion (mapv8 <->mapv9) when use m8 or m9 desktop software. Is it not better to use a gis database and be able to have a style file that can be share beetween m8 and m9. gis data base don't store style and each gis software have their own way to manage style.gis server use HTML and svg and they both use css.We can share projection file, pure data text attach to gis data (Vector and raster)...but no style !!!! Really wish CSS support beetween m8 and m9 !!! Style in HTML Can be define using json in HTML client side browser so style import/export for gis web server should also appear....in m9!!!!

union, doc , APIand most important deepl & keyboard shortcut

https://pro.arcgis.com/fr/pro-app/latest/arcpy/mapping/python-cim-access.htm

I think class and id value use in html to style Html tag or shape in svg will be base on column value in manifold !!

union, doc , APIand most important deepl & keyboard shortcut

i post the test in another thread in this forum

union, doc , APIand most important deepl & keyboard shortcut

Since we do not have visibility to the suggestions submitted to date for requested features, it would be nice if Manifold posted some sort of features survey or request count received. Then it would be good if customers could do something simple like a thumbs up or some other method other than the email submission to sales (that apparently needs to be sent in non HTML for mat to get indexed at Manifold.

Maybe require the response or thumbs up to a survey to have their serial number added to it to prevent someone from spamming the results or scamming the system to get their request moved to the top.

Demetri and Adam are great at responding to the forum and explaining things, but at times it seems like they are going to deep on a topic. It is true that Manifold 9 is a amazing software package, but I have said this many times and will say it again, the price point of the software entices many to buy it whom are not serious gearheads on databases, sql and all the advanced things Manifold can do. They are so smart on a topic they are not picking on on the simple frustrations an average Joe user who does not live in the GIS world are having.

Maybe if they were to have to teach a non GIS person how to make a map or some basic analytic task in person and hear and see their confusion real time, it might help direct some efforts differently.

Then it would be good if customers could do something simple like a thumbs up or some other method other than the email submission to sales

The primary objective of the suggestions process is to acquire high quality suggestions whose implementation would make best use of very expensive development resources.

It's critical when investing hugely expensive resources to know, for sure, that they are being invested into something that is genuinely important for users. That's non-negotiable. There has to be some real evidence that what's requested is really important to the user.

Making sure a suggestion is important to users is something the current suggestions process does very well. When people really care about something, wild horses cannot stop them from sending in a request. In contrast, when somebody doesn't really care about something, they don't bother to send in a request. Things that represent genuine trends will, for sure, get many people suggesting them.

Mechanisms like web surveys in social media tend to have the opposite effect, of magnifying things that people don't really care about, because they make it too easy for people to click a "like" button on something that they never thought about before and never will think about later.

It's also critical to get a sense of people's priorities. There, too, people who send in suggestions usually are not at all shy about being explicit on what's more important to them and what's less important.

There is no lack of people who care enough about what they want to spend a few short minutes jotting down a request and sending it in. Many of them become habitual suggesters, and some of them get into fairly involved conversations with engineering and product planners about what they are interested in.

All that really helps to make expensive investments in new ideas, even if just one person has suggested them. There are people in this forum who have initiated significant new things that many people now benefit from even though they were suggested by only one person. Many such new features also involved fairly intricate conversations between the suggester and Manifold staff, to bring the new feature into being.

Maybe if they were to have to teach a non GIS person how to make a map or some basic analytic task in person and hear and see their confusion real time, it might help direct some efforts differently.

Ah, but do you really want Manifold to spend expensive development time on creating products for non-GIS people? Wouldn't you rather Manifold continued to create really powerful, easy to use, tools at very low cost for people who either are into GIS or who are willing to learn a bit so they're not totally non-GIS people?

I'd respectfully remind you that non-GIS people aren't the ones who buy GIS products. Non-GIS people have no idea what, say, the Spatial Analyst extension is to Esri's Arc series or why anybody would spend $5,000 to buy something like that. But those who do know what it is and who need to use it, are really happy to have a product like Manifold that saves them from having to spend thousands of dollars and which works better than Spatial Analyst at so many things while being much easier to use.

Those quotes on the Manifold website from people who do things in Manifold in 20 minutes that take days in Esri products aren't fake quotes: they're the real thing. What would those people do if Manifold dumped them to create products for non-GIS people?

There's also the need to respect the interests of people who regularly use the software as an important part of their work. Very large, very capable software that's designed for efficient use by people who have learned it almost always has a higher initial learning curve than software which trades off an easier start for fewer capabilities and less efficient workflow for experienced people.

Photoshop is the classic example: it's brilliant, efficient software for people who have learned it, but it is very hard to learn for people who don't have prior experience in bigtime graphics editors. But there's no way anybody who uses Photoshop would want its stellar efficiency on the job to be reduced to make it easier to learn by beginners. You're only a beginner for a short while, but then you have to work with the thing for years, so it's smarter to want a product that is easier to use for those many years even if it takes a few more days to learn in the beginning.

9 is the same way. When you learn 9, it delivers super efficient workflow, far easier (for most things) than the workflow you need with packages like ArcGIS Pro. But if you don't start by learning the basics in a systematic way, you'll discover that the user manual is telling the truth that failing to learn the basics will result in unnecessary frustration.

I've taught a lot of people how to do GIS using Manifold products, including Release 9. I've taught people with no prior GIS experience, but they've all had basic computer literacy, say at the Microsoft Office level. Those people who read the topics I recommended in the order I recommended all did fine. Being willing to invest some time into learning the basics really does pay off.

You're right, of course, that the low price point of Manifold opens access for a wider range of people than, say, the much higher price point of something like Oracle. Usually when somebody spends $15,000 for a software license you don't have to tell them that they need to invest some time into learning it. You don't get that effect with an inexpensive product.

That's OK. Manifold would rather keep prices down for people who really need the products and are willing to learn how to use them.