Because of the shift towards an API, the FlatlandASP class can be split into a solver and a simulator.

Each of these end up as separate features:

• solver with statistics, models and actual solutions
• simulator to simulate/test and visualize the solution in the environment at each step

The asp instance generation should be completely independent of the encoding. Thus a minimum instance description should be provided that only describes the flatland environment in terms that are a direct representation.

Suggestion:

• cells with coordinates, orientation and possible directions
• schedule with agent id, start and target positions, starting orientation and earliest departure
• some map that maps a direction to an actual position change

In order to save custom maps, for example created in an editor, an endpoint to save them is necessary.

This endpoint should accept very specific input.

It should be possible to store either an entire Flatland environment or at least enough information to recreate a given environment.

EDIT: Some additional features are required:

• #10
• #11

The user should be able to view models, paths, actions, statistics etc. of any already found solution.
To achieve this, the solution has to be uniquely identifiable.

One way could be, to simply add environment_name, encoding_name and number_of_agents into the file name of the solution. This approach would however result in potentially very large urls if the name is used as a query parameter.

Another approach could be to instead take these parameters, hash them to some fixed length and use this hash as a unique identifier.

A file could be added which stores hashes and their respective configurations.

The name is just too long at the encoding is basically the current main encoding for all maps, not just for passing siding maps.

The calculated horizon Flatland provides can be too small under certain circumstances as it ignores collisions which may force trains to take way longer paths than the shortest ones.

Thus a way should be added to set the limit manually in case it doesn't fit (or find a better formula)

Calling .reset() on Flatland environments inside of the solver and simulator introduces a side effect that's hidden for outside viewers.

Instead the call to reset should be done after instantiating the environment and the already reset environment should be provided to both, solver and simulator.

Recently an error occurred in a similar project (actually the error occured twice in different ones) because the developers did not call .reset(). They then tried to find help in my project, but since the call to .reset() was hidden, they - and I myself after investigating their problem - spent too much time realizing that all that was missing was a simple .reset() call. If that call was outside the classes instead of in their initialization methods the solution would've been immediately obvious.

Some files got pushed that are no longer in use or shouldn't have been pushed in the first place. They should be removed to clean up the project.

main.py should be the entrypoint of this application, it should only be concerned with setting up the necessary basis like api with routers and actually run the server.

An endpoint should exist that tries to solve a specified environment with a specific encoding

This error message is just annoying.

Currently the solver seems to have too many (and apparently confusing) side effects.

• creates an instance, currently the name can't be set, only the instance generator
• uses fixed step_limit
• adds .lp to encoding name which actually already caused confusion when someone used the project
• save takes the solver data and stores it in a json file

The problem:

The class so far seems like a mix between an abstraction over clingo/flatland and not being one. I think the class should be either changed to be a real abstraction (probably no clingo control as input, fixed subset of allowed parameters) or to not be one at all.

Suggestions for removing abstraction:

• remove instance creation entirely from the solver, instead of an instance generator it should directly take in an instance (this also removes the step_limit side effect)
• remove save function, storing json should instead be a normal file utility
• don't add .lp inside the solver

Further thoughts:

If all suggestions are implemented, the solver would just use normal clingo functionality such as adding the encoding to the clingo control, ground and solve. The only actually useful functionality left would be the extraction of the last model/solution data. So instead of a solver this just is a callback container.

Because of the future introduction of an actual base instance that is independent of encodings, thus only provides the actual minimum data, the old BaseInstance is no longer the base.

It should be considered to completely rework the instance generation because if the instance is independent and only a single one is used, then the entire concept of multiple instance formats is not of any use.

Since the project changed from being a package (because it was too small and meaningless) to an application (in the form of a backend API) the user now should be presented with information on how to run and interact with it.

In the last added environments the sparse_line_generator can't find a proper orientation because all city orientations are set to 0.

To solve this the proper city orientation should be supplied. This requires a corresponding issue in FlatlandASPView.

All maps should be replaced with versions using proper orientations.

Currently ASP instance generation/storage is part of the core capability of FlatlandASP. This makes sense, as it works with basic structures and generating instances from an environment is a fudnamental functionality required for the project to even be functional.

However the same could be said about environment generation/storage, which currently resides in the environments feature.

This seems inconsistent and should be changed. Either both are part of separate features (ASP instance generation could be part of the solver) or both are part of core.

There should be an endpoint to load an environment and display its data.

This may require separate endpoints for json and pickle.

Implement endpoint that shows all currently loadable environments.

Wiki pages should be updated with more information about the ASP instance and encoding, especially the thought process behind each element.

A custom logger config would be beneficial as it can show which module has logged which messages, granted logging modules create a new logger with a name.

After the change in project structure due to the /data/ directory the README is no longer accurate.

Test and benchmark environments are helpful in finding better encodings and ensure that they work at each iteration.

• #52

environment_crud so far only provides the ability to load directly from pickle or load EnvironmentData, it should be possible to load environmetns from json just like from pkl. Maybe add an optional parameter for agent variability and a custom line generator.

Feature router is missing, needs to be committed.