Subscribe to this thread
Home - General / All posts - Layer Properties Suggestion
BerndD

129 post(s)
#28-Sep-19 14:17

In case you guys want to support the suggestions below, please go ahead and copy and send this with your amendments to Manifold (http://www.manifold.net/info/suggestions.shtml):

For drawings and labels we suggest to add the following parameters to the properties:

Minimum zoom

If blank, show component at any zoom level. If a value is entered, show component at any zoom level above this value and hide it otherwise.

Maximum zoom

If blank, show component at any zoom level. If a value is entered, show component at any zoom level below this value and hide it otherwise.

Render zoom

If blank, redraw points and labels at the same screen size regardless of zoom level. If a value is entered, render points and labels at their specified point sizes only at that zoom level and render points and labels at a larger size when zooming in beyond the specified render zoom level, and render them at a smaller size when zooming out from the specified render zoom level.

For images we suggest to add the following parameters to the properties:

Minimum zoom

If blank, show component at any zoom level. If a value is entered, show component at any zoom level above this value and hide it otherwise.

Maximum zoom

If blank, show component at any zoom level. If a value is entered, show component at any zoom level below this value and hide it otherwise.


The Future of Spatial Data // www.drahola.com // www.geocockpitug.de

tjhb

8,883 post(s)
online
#28-Sep-19 22:38

In case you guys want to support the suggestions below, please go ahead and copy and send this with your amendments to Manifold (http://www.manifold.net/info/suggestions.shtml):

On the other hand, from the Suggestions page you link to:

The product planning process values independent votes for similar features much more greatly than a cluster of votes promoted by an advocate. If many people independently throughout the world come to a particular conclusion and find a new feature important enough to write, that tells Manifold it is something that is really important enough for many people independently to decide to suggest. In contrast, if someone makes a posting on a newsgroup that says "I think feature X should always have default setting Y... write to manifold if you agree" and Manifold get a few dozen letters saying "I agree" with a copy of the posting, that tells Manifold the default setting was really not a big enough deal for more than one person to feel strongly about, because no one else noticed it or cared until the issue was raised in a news group.

BerndD

129 post(s)
#30-Sep-19 10:26

Hi Tim,

I could easily list a dozen topics where it is unclear to me what other forum members think about. So in order to find out you have to ask others about their opinion and thereby maybe raise some awareness. Which is a good thing. They can boost a topic or bury it for a long time by simply filing a suggestion or not.

If asking forum members to file a suggestion as well is in the grey zone I can skip that part. No problem there.

In regards to the suggestion topic I'd like to add that sure, I can make a suggestion. But only Manifold knows the real hit list. Maybe a little bit more transparency would help, like a topic about the roadmap that goes beyond the next build. For example I am wondering what has happened to the map server capabilities. We are beyond the timeframe that was mentioned in some previous posts. I am not blaming you because I know there must be a reason why it hasn't surfaced yet. It would be good to know if this is due to a priority change based on suggestions and if it is still on the radar. Just a thought.


The Future of Spatial Data // www.drahola.com // www.geocockpitug.de

Dimitri


5,552 post(s)
#30-Sep-19 15:38

map server capabilities [...] due to a priority change

Good questions. Just my two cents on the topic...

I think it makes sense that the biggest interest in 9 arises from those things which you can't get elsewhere. If you already have 8, or ESRI, or whatever, and it does what you want there's no need to buy and learn something new. Sure, if doing what you can do in Arc is somewhat easier or faster in 9 that will drive interest. But if you can only do what you want in 9, and that task is mission critical, well, that's something you can't ignore, and it really drives interest. :-)

As a rough simplification, the unique aspects of 9 are mainly about working with data that is big enough that 8 or Arc are too slow, and mainly about working with DBMS connections and other data access that you just can't do in either 8 or Arc. Historically, people and organizations that have dived into 9 need to work with a million vectors today, and in a way they can't realistically do with alternatives. I think that as part of doing that work they naturally are most likely to speak up about features and capabilities they need which are directly involved in that specific work.

That's different than presentation and cartography, which (after you crunch bigger data) you can do in 8 or Arc or many other packages. Map serving is like that, in that there are many options. If you have 9 you can load PostgreSQL with the results of your data crunching and use free map serving software to publish those results to the web. It may not be as convenient as it would be to have 9 automatically be a map server too, but at least there are alternatives.

That's my theory why there seems to be more interest in filling in holes in things like vector editing. If you're editing a couple of million objects, you need the right capabilities in the tool you are using, as there's not an option to export back out to ESRI and then wait forever. You want to do all you must do in 9. Same with raster extensions and tools, where if you want to compute something in rasters you really want to take advantage of 9, get more capabilities as fast functions, then added for ease of use as transform templates and so on.

That's not going to stop 9 from coming out with server capability. But I think it explains the current priority in the near term on filling in missing parts of editing tools and many other "small" things, some ongoing work with rasters and so on.

I also think that as 9 expands there are more and more people who are choosing it not because they don't have any other choice given the data sizes they're working with, but because they like the flexibility of it, they like the quality, and as more and more tools are being added they don't want to have to drop out of 9 into 8 or back to Arc or some other tool to do something they want in cartography or presentation. So that's a rationale for expanding capabilities in legends and layouts.

One more thing on servers: there are many common issues between things like distributing processes between multiple machines, enabling cloud-resident operation of worker processes, and enabling server functionality of Manifold as a web server publishing to clients, be those clients browsers or Manifold client sessions. The easiest thing in the world is to do a one-of-a-kind web server, like IMS in 8 or mapserver or other classic GIS web servers. People often take one-off approaches just to get the thing out. But then they find themselves doing a different one-off approach just to get out client-server ability between an instance of Manifold as a client on one machine and Manifold as a server on a different machine, and yet another one-off approach for cloud and yet another for distributed processing. All that adds up to inject orders of magnitude more complexity into the thing than doing a unified approach (when possible if in truth some server manifestations really are just different sides of the same coin), and such extra complexity very rapidly builds up to where software cannot be maintained or extended or built to crashproof quality.

So there is a lot to be said for not pushing on the map server right now, but perhaps waiting a couple of months on it until the other server work is further along so that a focus on servers can be done in an integrated, maintainable, flexible way. In the meantime, effort invested into steadily filling holes in vector editing, adding raster capabilities, adding some more good things in layouts, introducing legends, and so on, is effort in a good cause, helping many users.

tjhb

8,883 post(s)
online
#30-Sep-19 16:34

Great post Dimitri, especially (I think) the sentence that kicks it all off...

I think it makes sense that the biggest interest in 9 arises from those things which you can't get elsewhere.

...as well as the words that value groundwork to limit product entropy over time.

Mike Pelletier


1,629 post(s)
#30-Sep-19 17:45

That all makes good sense to me as well. A few more thoughts on the attractiveness today of 9 compared to other GIS packages.

1. People want to invest time and energy into a product with best potential. Mfd 9 seemingly has the best foundation for the future in terms of speed, scaling projects small to big, SQL flexibility, and stability. This is huge and allows over looking many current deficiencies. On the flip side, dropping in/out of GIS software is a pain and a motivator to overlook deficiencies in other software.

2. Mfd 9 is becoming a really good tool for sharing data with non-GIS folks. Clean interface makes it easy to teach others simple tasks. Easy to transfer a project. Easy to install software. Free viewer.

3. Access to web servers compared to 8.

Labeling needs to be better (curved labels for sure) before any significant cartographic presentation is done, otherwise it leaves a bad impression.

Vector editing needs a way to combine/split features. Whether big or small data, vectors are core work and having slick tools to manipulate them is a big part of the relative enjoyment associated with the software.

A georeferencing tool is another core tool needed. Big rasters need to be in the right location and 9 should be the tool to put them in the right space.

Dimitri


5,552 post(s)
#01-Oct-19 12:13

Labeling needs to be better (curved labels for sure) before any significant cartographic presentation is done, otherwise it leaves a bad impression.

[...]

A georeferencing tool is another core tool needed. Big rasters need to be in the right location and 9 should be the tool to put them in the right space.

Agree. Should happen soon.

Vector editing needs a way to combine/split features. Whether big or small data, vectors are core work and having slick tools to manipulate them is a big part of the relative enjoyment associated with the software.

Also agree. The question is what, specifically, is preferred. How do you like the ArcGIS Pro tools?

Mike Pelletier


1,629 post(s)
#02-Oct-19 18:05

Not familiar with ArcGIS Pro.

How about the goal being something fast to use and simple and covers 90% of need with the other 10% being done by more cumbersome means like the transform pane.

Perhaps it could work something like this. Select a feature(s) to the modifier, either add or remove. Then alt click a feature that is to be target, which is modified by the selected objects. Press M to merge or R to remove.

If the selected object is a line it splits the polygon. If both are lines, then the target line is split. If the selected object is a polygon and the target is a line, the polygon removes the overlapping portion of the line.

Dimitri


5,552 post(s)
#03-Oct-19 08:50

I just asked about ArcGIS Pro as a useful example. It's not a bad standard for a quality, classic GIS.

Pro is useful because ESRI has good insight into what professional GIS users do on the job, and what tools and workflow they use most frequently.

ESRI also spent immense resources on planning Pro as their next generation desktop replacement for prior Arc versions. ESRI's choice of tools and the way they are presented in a hierarchy of ease of access shows which ones ESRI expects to be used most frequently. ESRI's opinion seems to be that ten or fewer tools make up that 90%, when it comes to vector editing.

Pro also is useful as an example of what millions of GIS people are trained to expect. If you have a choice how to do something, all other things being equal you can do worse than to look at what ESRI does. That can help when resolving details like...

If the selected object is a line it splits the polygon.

OK. Suppose the polygon is branched? There's a big area with a hole in it and various islands scattered around, all part of the same area. You draw a cut line through the big area with a hole in it, expecting that to split the big area into two area objects. What happens to all the branches? Do they become branches of one side, of the other side, or randomly assigned with some islands to each? What happens to the attributes? Does every resulting object get the same copy, or are some fields proportionately distributed?

9 has ways to handle such issues that ArcGIS Pro does not (for lack of internal database infrastructure within Pro) so 9 could handle such cases "better" than Pro. But there's still a lot to be said for respecting what ESRI does, at least as a sample case to keep in mind.

Mike Pelletier


1,629 post(s)
#03-Oct-19 15:46

Glad to hear your tracking Pro for all the reasons stated. Learning from and improving upon :-)

Dimitri


5,552 post(s)
#30-Sep-19 08:51

It seems to me this would be very dependent on use, and thus should be a property of a map.

Suppose zoom ranges are a property of the drawing. You could then click open a drawing and not see anything because default zoom to fit places it at a scale where the zoom range settings say "do not display". I think as a general rule of thumb that when you open a drawing in its own window, as much as reasonable the default viewing settings should try to show the contents of the drawing.

What might work better is if zoom ranges were properties of a map. You could add another Layers pane setting to opacity/pick/snap, for Scale range. That would also allow the same drawing to be used in different maps with different uses, where in some maps you want the drawing/image visible all of the time and in other maps you only want it visible within certain scale ranges.

BerndD

129 post(s)
#30-Sep-19 11:59

Both good ideas. I second that.


The Future of Spatial Data // www.drahola.com // www.geocockpitug.de

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