I do this (get midpoint of a polyline) by calculating the length of the line (LengthCalculator) and use half of that value and a Snipper to create the point.

Thanks for that, @nielsgerrits . I’ll take a look.

HI @nielsgerrits . I’ve used that approach with some success. However it’s giving me points for the centre points of each vertex of the street. For example, it’s created two points for Nelson Square. Because if yiu look at the lines geometry for Nelson Square there are two clear parts…

However in the source street network data there is one record per street. Yes, these streets are made up of one or more vertices (one section between intersections with other streets) but they are one record per street.

Is it possible to treat each incoming street record as a one whole line? 

Thanks.

Interesting question! The closest I’ve come to a solution is to first Aggregate street lines (group by street names or similar attribute), then extract a centerpoint. This point will of course not be exactly on the lines, but using an AnchoredSnapper you can snap it onto the line (again grouping by StreetName to make sure it snaps to the correct line. 

Thanks for that, @jonas_nelson . I’ll give it a go.

I have done this / encountered same issue, with Eg. finding the middle point of property street frontages for the edge cases where a property can have disjointed frontages/frontage “gaps” on the street frontage edge.

The only solution I’ve put in place so far though requires a few Transformers:

1. Counter to add a Line / Street Unique ID if does not already exist.  Needed below in Step #5 for Adjacent Feature Processing + Conditional Values.
2. LengthCalculator to create an Attribute of Total Length for the Aggregate/Multi Polyline.
3. Snipper as per @nielsgerrits …..although this can be simplified to not need length functions as Parameter values.  Just use Length (Percentage)  Start = 50 (percent), Stop = 50 (percent).   This will handle the simple lines, and spit out the multis/aggregate street/lines to the Rejected Port.   Other change is to “Reject Features” rather than “Deaggregate” them to force multipolylines out through the Rejected Port,
4. On Snipper Rejected Port -  Send Rejected Features to Deaggregator
5. Then to AttributeCreator with Adjacent Feature Processing enabled (1 Preceding Feature) + Conditional Values.  Start the first deaggregated Feature part of the line/street with “StartM” = 0 , and “EndM” = StartM + Feature Length().   If the next deaggregated feature has same Line/Street ID as preceding feature,  for this Condition “StartM” = Previous Feature “EndM” etc. “EndM” = StartM + Feature Length()
6. Then to Tester to find which of the deaggregated lines contains the original Aggregated line mid-point.  This the deaggregated segment where “StartM” <= Total Length/2 (from Step #2) AND “EndM” > Total Length/2
7. Snipper on the Tester = Passed Feature per Line/Street Part that is the the deaggregated segment that contains the mid-point.   To get the true mid-point is Snipper (Length):  Start/Stop Parameter Values = Total Length/2 (from Step #2) - StartM

This will find the exact mid-point of an aggregated/multi polyline.

...if only Snipper could handle Multilinestrings to make life easier!

@jonas_nelson . That worked well, thank you. Because some streets are just one vertex (A to , I had to also draw in the ‘untouched’ streets from the Aggregator. Without that I was getting 1974 instead of 2145. I included a geometryFilter to filter the points only. I can take it on from here with coordinateExtractor etc.

Thanks for your help, and to @nielsgerrits.