Subscribe to this thread
Home - General / All posts - Fixing movable points to reference lines
Ian
268 post(s)
#10-Jan-18 21:47

I am splinting up paddock cells - just cutting polygons in half. The polygon to split may only have four corner points and I want to split it on the sides where there are no points to snap to so I'm free handing a polygon over the top of the one to split to find exactly half the area then free handing points onto the spot where the line would go to split the polygon. I can split the polygon with the split with transform but I still have the issue of getting the exact point on the line. My question is; Can I overlay one polygon on another and fix a point onto a side (line) of the bottom polygon and slide it up and down the line without moving the bottom polygon line? Not sure if all that is very clear but hope someone can help

tjhb
10,094 post(s)
#10-Jan-18 22:30

Ian,

just cutting polygons in half

That is not trivial. Even for the quadrilateral case where

The polygon to split may only have four corner points

though that is certainly do-able automatically in SQL. (E.g. see here.)

More vertices will need different approaches.

If geometries vary, you might be best to keep doing it by eye.

In that case there are some friendly tools in Manifold 8.

(1) In the Info pane, enable Show Intrinics (the button second from the right). Write down the area of the original area, from column Area (I).

(2) You can easily bisect any edge. Select the area for editing (Ctrl-Alt-click), then hover over the edge to be bisected, right-click, choose Coordinate > Add Mid-Segment.

I would do that on the longest edge, since that will minimise the length of new fences in the subdivision, if fences are required. (I'm not sure if that is exactly or only roughly right. Just intuition for now, but I hope a good start.)

(3) Now activate snap to areas, and draw a "half" paddock by eye, using the coordinate added in step 2. Disable snaps (spacebar) for that last coordinate, to be adjusted next.

(4) Now also activate snap to segments (and re-enable snaps). Now you can adjust the "half" area drawn in step 3, by shifting coordinates along edges, aiming for an area half that of the original paddock. Inspect Area (I) for the adjusted area after each change.

Inexact.

Ian
268 post(s)
#10-Jan-18 22:40

Thanks Tim, was hoping there was some way of locking the point to the line without moving the line and get it exact. Will persevere.

tjhb
10,094 post(s)
#10-Jan-18 22:45

Ian,

was hoping there was some way of locking the point to the line without moving the line...

Snap to segments does that, exactly.

...and get it exact

Getting the area exactly divided by two is generally harder.

If the paddocks are all quadrilaterals (only four coordinates) then it can be done exactly and *relatively* simply in SQL.

If only some paddocks are quadrilaterals then those could be subdivided automatically, the others done by eye.

Ian
268 post(s)
#10-Jan-18 23:57

So it does, thats just what I was after thanks Tim

danb

2,064 post(s)
#11-Jan-18 03:09

This would be a nice sort of add-in to have. I have needed to do this sort of thing several time in the past.

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//001t000003wp000000.htm


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

tjhb
10,094 post(s)
#11-Jan-18 05:12

Dan,

Is there any chance you could give an A-B example of how Arc chops up detailed areas into N parts each?

Does Arc present options? Or does it just “know”?

[Edit] I see from your link that it does. Quite impressive.

What is most important for Manifold to do as well?

We can already do any and all of this in code.

Exactly the same can be buiit in.

tjhb
10,094 post(s)
#11-Jan-18 05:28

Not for the first time, I think Manifold should facilitate “closed” add-in modules, i.e. which cannot be readily decompiled, to encourage development of useful extensions for a fee.

The investment in time should be worthwhile.

ColinD

2,081 post(s)
#11-Jan-18 05:42

Agreed Tim, much like the Apple/Android app model. Manifold can have their own App Store that users can contribute to.


Aussie Nature Shots

KlausDE

6,410 post(s)
#11-Jan-18 06:59

..with their own CrytoRadian as international currency. But run by a subsidiary hold by early adopters of Mfd9 before it gets listed on the stock exchange


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

adamw


10,447 post(s)
#11-Jan-18 08:17

Just to clarify for the future, you want: (a) to be able to ship queries / scripts in the way that the user can't see the sources, and (b) to be able to protect them from copying to another machine somehow, correct? The former can be accomplished by compiling an addon into a DLL (then possibly running it through an obfuscator, but that's likely overkill). But the latter is really tough (we can supply you with a hash of a serial number, but what then? or are we talking about this handled by our servers and the addons being sold through part of our store? that's certainly doable, but this seems too high a place to start).

Maybe we should start with public no-payment addons updated from Github - or maybe from a service on this forum - integrated into the UI (ie, the addon advertises where it is stored globally and we then perform update checks on launch / perform the update if there is a new version).

tjhb
10,094 post(s)
#12-Jan-18 00:28

I'm not sure what's best.

(a) Yes, and compiling to DLL might usually be enough.

(b) It might be enough to add an API function to give a hash of the serial number, plus a GUI interface to return the same hash (maybe through the About box). The purchaser could safely supply the hash to the vendor, who could embed the given hash as a constant in the script or suite (a trivial effort), and run only if the API check passes. That would be simple enough on a small scale.

Thanks for thinking about it.

I like the ideas in the last paragraph as well, in parallel (or if necessary, first). Sounds a bit like NuGet. Buggy scripts might be a problem, liability would have be to be clear since a bad script could do a lot of damage to data.

danb

2,064 post(s)
#12-Jan-18 05:47

Buggy scripts might be a problem, liability would have be to be clear since a bad script could do a lot of damage to data.

I was thinking more about factory produced add-ons here similar to Surface tools but perhaps more focused and encompassing such as a hydrology tool set similar to Arc Hydro Tools, a network tool set, a remote sensing tool set etc, etc.


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

danb

2,064 post(s)
#11-Jan-18 19:32

@ http://www.georeference.org/Forum/t140418#140431

I have always believed this sort of thing would be great and something Manifold should be doing once the platform is complete.

Manifold are terrific at building an incredibly robust and flexible platform but in my opinion sometimes fall short of providing more complicated prebuilt tools to facilitate tasks such as that posted. Sure these can be coded and that is part of the beauty of the Manifold way, but I would argue that such a task is beyond the reach of many including myself.

I think it would be fair to say that out of the 16 or so GIS professionals I work with, there are only two that wouldn't be scared off by SQL or even transforms (and I am one on them). Admittedly I am speculating but, would guess that our team is not untypical of other GIS teams around the globe and this is were the likes of ESRI really shine.

ESRI have some great prebuilt tools that do some very useful things. Many of these things Manifold can do more easily and in a much more flexible way, but to have a library of prebuilt paid and free add-ins that do exactly what they say on the tin of the sort I posted would be wonderful (Especially if they could still remain accessible to the object model for incorporation in custom scripts).


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

adamw


10,447 post(s)
#11-Jan-18 08:22

On topic, the splitting is perhaps best done using a script. We were also planning a helper query function in 9 that would simplify it dramatically (might do some transforms based on it as well).

jw15 post(s)
#11-Jan-18 19:00

Different workflow, but would finding Centroid (Weight) and drawing a line through that be accurate enough? Docs say it's approximate, but seems like for simple polygons should be pretty close.

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