-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Processing] Split with lines #3798
Conversation
Rename algorithm SplitLinesWithLines to SplitWithLines Accept polygon as input, too Use only selected lines to split with (if processing is set to use selection only) Issue log message if trying to split multi geometries Update help
to pass test
in order to pass test
By the way- I've been thinking about 0e2ef06#diff-82c77937447cc4743b51cd2f14513bf9R91 (no handling of multi* geometries), and I think a good approach would be to follow how PostGIS' split works. In PostGIS, a split will always return a multi geometry consisting of the newly split parts of the original geometry. Then it's up to users if they want to convert this to single parts in a separate step. If we did it this way we could nicely handle multigeometry inputs. What do you think? |
Hi Nyall,
this makes sense, however it must be clearly communicated to the user
that the data type of the output may differ from the input's data type
(single versus multi geometries).
Will give it a try in the next couple days
Am 24.11.2016 um 00:10 schrieb Nyall Dawson:
… By the way- I've been thinking about
0e2ef06#diff-82c77937447cc4743b51cd2f14513bf9R91
<0e2ef06#diff-82c77937447cc4743b51cd2f14513bf9R91>
(no handling of multi* geometries), and I think a good approach would be
to follow how PostGIS' split works. In PostGIS, a split will always
return a multi geometry consisting of the newly split parts of the
original geometry. Then it's up to users if they want to convert this to
single parts in a separate step. If we did it this way we could nicely
handle multigeometry inputs. What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACasyfJHCg_R1LyukNwbIUKcGoEAJo4Kks5rBMf1gaJpZM4K6uC4>.
--
Bernhard Ströbl
Anwendungsbetreuer GIS
Kommunale Immobilien Jena
Am Anger 26
07743 Jena
Tel.: 03641 49- 5190
E-Mail: bernhard.stroebl@jena.de
Internet: www.kij.de
Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe
__________ Information from ESET Mail Security, version of virus signature database 14495 (20161124) __________
The message was checked by ESET Mail Security.
http://www.eset.com
|
@nyalldawson , @bstroebl , FYI, I ran into this dilemma with processing's vector overlay operations (difference, union, etc.), whereas due to the nature of the operation singlepart features could result in multipart features. I opted to go the PostGIS way and always return multiparts. As with the vector overlays, if a user needs a singlepart output, he/she can run multipart to singleparts algorithm against the output of "split with lines" alg. |
totally agreed; would be good if all processing algs did it this way (accept multi as input, probable output is multi, too), so one could run multi to single as last step in a model and had not to care about it in between. |
@nirvn, @nyalldawson I already implemented the multi output but there is another problem: If a single line crosses all of a polygon the polgon is split alright, but if the line consists of two separate line features current behaviour is to not split. Would that be the outcome you expect? |
this is a new pull request because I screwed up the last one
It replaces old SplitLinesWithLines algorithm by a new algorithm called SplitWithLines which splits lines and polygons (hence its name).
I implemented all of Nyalls suggestions and it runs pretty smooth now.