Coordinate systems is maybe not something you are faced with every day, and might lead you more to the gaming industry, but nevertheless are coordinate systems something you will face sooner than you think. The pixels of your screen for instance already define a coordinate system. This system has the zero point in the left top corner which is similar to how we read in standard languages such as English. We start at the top and go to the bottom, and on each line we read from left to right.
The coordinate system of your screen is a bit special, as it does not allow for negative values and works only with natural numbers. Because of this implicit coordinate system something as simple as showing something on the screen already requires a conversion or mapping. In this blog post I will go into more detail as to what problems can arise and what you should take into account.
Libraries and frameworks such as JavaFX hide away all of the low level details with converting objects into the coordinate system of the screen. This should make it a lot easier for you to show objects or something else. But there are some caveats to this and if you have some specific needs you could end up in conflict with the framework.
Something you have to take into account first, is the scale. If you have objects and you measure their size in a certain unit, this might not be the best unit to be used directly with the framework. For example: your objects are all pretty small (as in a few millimeters), but your whole map is very large (in the sense of meters) then your internal measurements are likely in millimeters (for precision). Translating this one-on-one to the framework can result in only showing a few centimeters of your map on the screen with the default zoom factor.
This means you have to decide whether you want to mess with the zoom factor, and possibly end up with a very small zoom factor just to be able to see everything, or if you want to do a translation. Keeping your measurements in the logical part in millimeters, but translate it to centimaters (and thus making everything 10x smaller) in the visualisation framework.
An example of an application I saw did something for which I can’t possible think of any reason why you would do it like this. Instead of respecting the axis of the visualisation framework they decided to introduce their own with an inverted y-axis. Doing something like this requires a very clear separation between coordinates in the logical space and in the visual space, but should be avoided for simplicity reasons if possible. One situation where it is impossible to avoid this is when mapping a higher dimensional space onto the two-dimensional screen.
The conclusion here is that introducing extra complexity should be avoided where possible, and using the default coordinate system offered by your visualisation framework should be preferred if it is sufficient. If not, then having a clear separation between logical and visual coordinates is a must as well as an easy way to convert one into another.