Feature: Allow multiple potential building connections

[jnettels]

This PR merges some ongoing development of DHNx

7da0502 Allow multiple potential building connections

DHNx requires connecting each building to the line network, e.g. the streets. To do this, create_object_connections() normally
finds the perpendicular line which represents the closest connection between building and street.

This commit updates create_object_connections() to allow more than 1 (default value) number of connections 'n_conn' to be created. During the optimization phase, the solver now has multiple options to choose from when finding the best district heating network.

This may be desired when the nearest street segment is not actually the best way to connect a building. In cases where a building has a street or path in the front and back, both may be valid options.

For each line segment that a possible connection has been attached to, its direct connections are ignored when searching for the next possible line segment. This mostly avoids obviously inferior alternative connections and helps find more relevant alternatives.

To allow this functionality, create_object_connections() had to be completely rewritten. But the default settings should
retain the old behaviour.

This feature increases the optimization time.

Further updates required for supporting multiple connection lines:

insert_node_ids() in geometry_operations.py

check_input() in optimization_models.py

153cd11 Simplify and improve run_point_method_boundary()

Previously, run_point_method_boundary() required consumer and producer data as input and repeated all steps for both data
sets. To avoid unnecessary code repetition, the duplicates were removed and the function now has to be called once with
consumer data and once with producer data as input.
Additionally, incorrect behaviour for some edge cases was fixed and support for the multiple connection lines implemented in
create_object_connections() was added.

Usage of the function weld_segments(), which welds continuous line segments together and cuts loose ends has been made optional via the parameter 'welding' (default is True)

The function process_geometry() had to be adapted to support the changes in create_object_connections() and run_point_method_boundary()

d9a05a5 Enforce reduction of 3D geometry to 2D

Most underlying functions (e.g. distance measurement in shapely) do not support 3D geometries. Having z-coordinates in the
data can cause issues in several places in the code, especially when e.g. buildings contain z coordinates, but streets do not.

The savest option currently is to force 2d on all input geometries, which is now the default in check_crs()

Other changes included in this PR

34d9664 Fix deprecations in pandas>=2.0
0932a07 Replace print statements with logger info and warning

[p-snft]

To run this branch, I had to merge dev, so that the fixes from there are applied here. It looks like the default behaviour is unchanged at least for the cases I tested.

Having said that: What is the status of maturity of this package? Should there be unit tests? At the moment, I have the feeling we do not want to enforce them so that development like this can happen.

[jnettels]

Hi and thanks for the review. I am happy to see that the default behaviour did not change for you.

I would agree that some sort of testing should be implemented. If you don't mind, maybe we should discuss this in a separate issue. I have prepared #148 with some first thoughts.

Do you approve this PR now?