Dive Site < City/Island < Country data structure

Discussions about Diving Log 6.0 - questions and hints
Post Reply
Storker
Posts: 7
Joined: Wed Oct 23, 2013 08:58

Dive Site < City/Island < Country data structure

Post by Storker » Wed Oct 23, 2013 09:05

In the current version (5.0.11), these data fields seem to be independent, making it necessary to enter all the info manually (e.g. filling in/choosing first country, then city/island, then site).

In e.g. Suunto Dive Manager v3, the location info is linked (site as a child of city/island, and city/island as a child of country), so when I enter the dive site, the program automatically fills in city/island and country. This makes both filling in the fields and managing the dive site information noticeably simpler.

Will this kind of data structure for the dive site info be implemented in future versions of Diving Log?

divinglog
Site Admin
Posts: 5041
Joined: Sat Feb 08, 2003 21:02
Location: Coburg
Contact:

Re: Dive Site < City/Island < Country data structure

Post by divinglog » Wed Oct 23, 2013 20:45

Hi

There is a soft linking based on your previous dives. When country and city fields are empty and you select a dive site, both other fields are filled in automatically.

Kind regards,
Sven

Kritta
Posts: 7
Joined: Sun Dec 04, 2011 05:15

Re: Dive Site < City/Island < Country data structure

Post by Kritta » Tue Dec 17, 2013 05:14

I would love to see this issue fixed. Surely a dive site can only be in one location, and a city or island can only be in one country - so a hard link associating a dive site with a city/island as well as a country would be sensible. It can't be hard to do - just add a city/island ID number field to the dive site table, and a country ID to the city/island table... it makes sense.

I recently did a trip and had entered all the dive site details into the database before I left. It was disappointing to see that I had to select the country and city/island after every dive on a new site, even though I had already entered the dive site details with this information before my trip. Please put this on the to-do list for a future update. :-)

The existing system is inadequate. Not only does it only work for the second (or greater) dive on a particular site, but if you accidentally pick the wrong site, and then change it, the city/island and country do not change.

I want to be able to choose a particular dive site, and have city/island and country automatically filled-in. To me this makes sense, is good database practice (as the data structure would prevent impossible value combinations), and really is a must-have feature.

divinglog
Site Admin
Posts: 5041
Joined: Sat Feb 08, 2003 21:02
Location: Coburg
Contact:

Re: Dive Site < City/Island < Country data structure

Post by divinglog » Thu Dec 19, 2013 20:43

Hi

I think a forced linking between the 3 level location fields would be too unflexible. I have in my own logbook several dive sites, which I've approached from different locations. As you can see in the image below, I was diving on the Elphinstone dive site in the Red Sea from at least 2 different shore locations and during a liveaboard trip, where I enter the boat name in the city/island field.

Another problem are the many import functions, which can import location data from many different file formats, where such a linking is usually also not available. So I cannot auto generate a fixed linking during import and it is up to the user to link the dives afterwards. There are also many duplicate dive site names out there, e.g. generic names like "Manta Point", which exist all over the world, so auto linking by name is also not possible.

In my opinion a fixed linking has also no advantages. The problem you described could be easily solved by using templates. The template function is very powerful, especially for vacations. I simply enter all data just once for the first dive of the vacation, and then I create a template. For all other dives, I simply apply the template with one click and all data, which is identical during the vacation, gets filled in automatically. This works not just for linked Country and City fields, but also for tank type, tank size, boat name, etc. This is a lot easier and faster and more flexible than just a fixed linking between the 3 level location fields. Does this make sense?
Image1.jpg
One dive site, accessed from 3 different locations
Image1.jpg (58.45 KiB) Viewed 6223 times

Kritta
Posts: 7
Joined: Sun Dec 04, 2011 05:15

Re: Dive Site < City/Island < Country data structure

Post by Kritta » Mon Dec 23, 2013 03:00

Thank you for considering my suggestion. I still think the data structure should be linked as it is logically impossible to have one dive site in multiple cities or islands, and it is impossible to have one city or island in more than one country. The examples you suggest are poor uses of the data, not a result of poor data structure.

The Elphinstone example doesn't make sense to me. You say you've used a boat name in a city/island field. A boat is not a city or an island, so that's an incorrect use of the data structure, not a problem with the data structure that I am suggesting. Also, approaching a dive site from a different point on the shore does not actually move the dive site - it is still in the same place and it is still associated with only one city or island and it is still in only one country. The information about the dive site itself is unchanged, even though you approached it from a different location or by a different means.

In regards to having multiple dive sites with the same name, again, this is a problem with how you are using the database, not a problem with the structure that I am suggesting. It is also easily solved by providing more information in the user interface where dive sites are chosen. For example, a drop down could have "Manta Point, City/Island name, Country name". Your database currently stores co-ordinates, depth, rating and comments for each dive site. These would be different for each "Manta Point", so clearly mixing-up different Manta Points should be avoided. There must be a separate entry for each Manta Point, as each will have different co-ordinates, depths, comments, maps and so on. While the name may be the same for two dive sites, the dive sites are not the same in other respects. This is a fundamental principle of database design. I'd be happy to explain further if you it would be helpful to you.

You say that the data structure I've suggested has no advantages. This is not the case. One advantage is that you only have to choose the dive site when you're entering details of a new dive, you don't have to choose the city/island and country as they will automatically be associated with the dive site. Another advantage is that you can view information that pertains to a certain dive site, such as seeing all the dives you've done at, say, Barracuda Point in Sipadan, without getting it mixed-up with any other Barracuda Point site in other locations. This would be good for reviewing details about a particular location to see how visibility changes at different times of year, how water temperature changes, etc. It also enables different users to compare logbook notes on a particular dive site. If, say, I export my data via the php interface, I would want users to be able to view Barracuda Point in Sipadan and not get it mixed-up with Barracuda Point in any other location.

Data structure is a very boring subject, but it is also very important. Your current lack of a data structure makes a mess very easy to create, such as if you mix-up dives sites with similar names but in different locations, or associate more than one city or island with the same dive site. Good data structure would make both of these problems impossible.

Your current database is a relational database, and as such it is appropriate to logically separate information in different tables, and then create logical relationships between them.

Your software is excellent in pretty much every other respect... but I think this is a fundamental problem with the current software that will create lots of problems in the future if you choose to implement features that require differentiation between different dive sites.

Happy to discuss further... andrew@quested.com.au if you wish.

Best wishes, and have a great Christmas. :-)

divinglog
Site Admin
Posts: 5041
Joined: Sat Feb 08, 2003 21:02
Location: Coburg
Contact:

Re: Dive Site < City/Island < Country data structure

Post by divinglog » Sun Dec 29, 2013 15:07

Thank you for your feedback. I understand your position and from a database perspective it makes perfectly sense. I considered a fixed relationship between the 3 location fields in the past and spend quite some time thinking about it, but in the end the fixed relationship had more disadvantages than advantages.

A dive site could certainly be linked to more than one City/Island. Take a look at the Maldives. I always log the City/Island where I stay during my vacation, not the City/Island near the dive site. So on the Maldives, dive sites are accessed from many different islands. When I stay during 2 vacations on 2 different islands and dive the same dive site, you cannot do this with a fixed relationship. And when I stay on a boat during a liveaboard trip for one week, there is no City/Island at all. That's why I enter the boat name for these dives, because this is my 2nd level location during this vacation. I do not care about the city on the shore nearby. Sometimes there isn't even a city or island nearby, because you're in the middle of the sea. "City/Island" is just an example label, you can enter here anything you want which makes sense to you as a 2nd level location name. Or you can enter nothing at all and just enter country and dive site name. This happens all the time when I see other people's logbooks.

Logging dives is a very personal task and everyone writes his logbook in a different way. It's the strength of Diving Log to provide this kind of flexibility. A fixed location relationship cannot provide this kind of flexibility.
Kritta wrote:One advantage is that you only have to choose the dive site when you're entering details of a new dive, you don't have to choose the city/island and country as they will automatically be associated with the dive site.
This is already working with the "soft linking" explained above. If the country and city/island fields are already filled with data, they don't change when selecting a dive site. This is by design, because users don't expect that the application changes data they've entered already.
Kritta wrote:Another advantage is that you can view information that pertains to a certain dive site, such as seeing all the dives you've done at, say, Barracuda Point in Sipadan, without getting it mixed-up with any other Barracuda Point site in other locations.
This is also possible with the tree browser from the statistics section. Click on "Locations" in the side bar to see all dives by a certain dive site.

Again, I understand your point of view and I've spend quite some time thinking about exactly this point for several years now. I strongly considered this when I created the version 5.0 database format. There are even CountryID fields in the City and Place tables in the database to create at least a relationship to a country. I'm currently not using these fields yet, but maybe I do this in a future update as an optional feature. But making a fixed 3 level relationship mandatory won't work due to the existing logbooks which can't be converted to such a strict data structure, because of the many import functions from 3rd party logbooks which could not create these links reliable, and due to the many 3rd party applications which rely on the data format of Diving Log and which would just break when I do such a fundamental change.

I appreciate your feedback, but unfortunately this isn't something that can be changed without causing many problems in Diving Log and other 3rd party applications.

Kind regards,
Sven

Kritta
Posts: 7
Joined: Sun Dec 04, 2011 05:15

Re: Dive Site < City/Island < Country data structure

Post by Kritta » Tue Jan 07, 2014 01:32

I appreciate your consideration. Thanks for the explanation.

- Andrew

reefhound
Posts: 53
Joined: Mon May 07, 2007 01:10

Re: Dive Site < City/Island < Country data structure

Post by reefhound » Fri Jun 27, 2014 14:09

I agree with kritta but understand the pitfalls of applying the complexity and rigidness of linked relationships to existing logs and large userbase. But I think it could be done cheaply by applying it as a data entry aid rather than a fixed linked. I'm seeing an option i.e. "Populate associated fields with Linked objects" that when you select a linked dive site it could fill in other fields that are related. Of course, then you could override those other fields.

Some additional fields I would associate with dive site, in addition to country and city/island, would be Fresh/Salt water type, altitude, and entry. Perhaps also visibility, waves, and current. The latter are often variable but sometimes pretty consistent. Again, the user could change them afterwards. And yes, I know and use templates often, which are very useful, but I find them more difficult to manage and a much blunter tool.

thimp
Posts: 1
Joined: Mon Jul 21, 2014 20:12

Re: Dive Site < City/Island < Country data structure

Post by thimp » Mon Jul 21, 2014 20:41

I have followed this issue for some time, and I know the Sven's view on the issue.
Still I would ask to consider at least an option to apply some form of referential integrity for the reason that I am loosing data. I attached two images for a site I had "linked" correctly (the place city and country had all locked items. After I saved the place again, correcting the name, first the link tot the place was lost, after correcting the link with the city was lost.
Also, when more fields are filled, and you change the place (I consider this the primary field) the other fields are not updated and the consistency is lost.

Please add a preference of some sort to force referential integrity, or an option to restore referential integrity. I have been restoring the data quite a few times by hand and doing this for 400 dives from the log window is boring, and doing this by editing the table is hazardous.
Regards, Thimp
Attachments
divinglog03.png
divinglog03.png (8.9 KiB) Viewed 5590 times
divinglog01.png
divinglog01.png (7.74 KiB) Viewed 5590 times

divinglog
Site Admin
Posts: 5041
Joined: Sat Feb 08, 2003 21:02
Location: Coburg
Contact:

Re: Dive Site < City/Island < Country data structure

Post by divinglog » Tue Jul 22, 2014 20:22

Hi

This issue is actually a bug which I still have to fix and not related to the structure feature discussed in this thread. A linked item should always stay that way, but this bug removes the linking for some reason. I'll try to upload a fix in the near future.

EDIT: This bug is now fixed. Please download this update and extract it into the Diving Log program folder. Now linked items should not turn into unlinked items themselve.

Kind regards,
Sven

CheeseAndJamSandwich
Posts: 58
Joined: Thu Jun 16, 2011 01:16

Re: Dive Site < City/Island < Country data structure

Post by CheeseAndJamSandwich » Sat Aug 16, 2014 08:48

I actually came here today because of this issue, and found this thread!

Question: When i type a dive site in, i'm sure it filled out the other two fields, but as i type more letters, it fails to then change them again, staying on the entries it guessed from the first letter typed... So i'm forced to pick the site of the pull down such that the other fields are correct... but this used to work right???
If i continue to type the necessary letters to select the dive site, i really, really want it to fill out/change the other two field, every time... and yes, Salt/Fresh. Altitude, etc should definitely be included in this if poss, all the stuff that just can't change (currents are variable)

We really need the option to make the links fixed. I'm never going to have my sites organised like you, i'll just go with the more normal unique dive site in one location... i think i'd be like 99% of us.
We don't want it it broken for 99% of us such that it works for the 1%... (the current design) ...we want it to work for 99% of us with the 1% having to create a work-around...
With an option to change this then we can have it working for both.
But currently it's broken for 99% of us.

I log a lot of dives (lucky me!) and all this extra work i have to do becomes exceedingly annoying, taking the fun out of the logging, preventing me from logging more... I want the logging to be fun and slick.

Compatibility with other software is key, but give us the options to 'break' this, with a note that it is broken when we change that option.

There are a few other areas where the database should be linked more... like the dive site details, there's also the Boats, they should be linked to the dive companies.... you could do this with divemasters/staff too... Dive trips can have more than one dive company... this would work 99% of the time and some clever options to make it work for the 1%/

Software is amazingly flexible so we should be making work for us 99% of the time.

divinglog
Site Admin
Posts: 5041
Joined: Sat Feb 08, 2003 21:02
Location: Coburg
Contact:

Re: Dive Site < City/Island < Country data structure

Post by divinglog » Sat Aug 16, 2014 17:36

I understand the need for a fixed structure for the 3 location fields and will implement an optional linking for countries, cities and dive sites. But this will require a database modification, so I ask you for a little patience until the next database update is scheduled.

I'll add a way to select a country and city for each dive site, which will then be preserved when selecting a dive site in the logbook window.

CheeseAndJamSandwich
Posts: 58
Joined: Thu Jun 16, 2011 01:16

Re: Dive Site < City/Island < Country data structure

Post by CheeseAndJamSandwich » Wed Aug 27, 2014 16:07

Awesome.

So...when it's in place...
If i'd previously set the Country, say using a template, or editing the table, would the choice on the pull-downs, now be refined to just show the linked city/island, dive site? Like it does now, if you step thru one by one?

Thanks again!

Post Reply