Carl,
The APRS packet definitions were designed to shoehorn into an existing?system. They took advantage of what existed and made it do something new. It wasn't a new system designed from the ground up, so there are some "unique" solutions. The APRS object definitions are no exception.
Just about every APRS packet is human readable to an extent... are they plain English with extremely detailed explanations of each component? Nope, you usually need to have a rudimentary idea of the structure. The APRS client software does that interpretation to pretty pictures and decoded information. But with a little knowledge, one can decipher most of the information manually. Knowing that?+900 means?+9MHz is one of those things you need to know. Most people don't even look at the raw packets, we spend a lot of time explaining packet contents to users in these forums.
As for your object timing.You mention you use timing between 25-45 minutes. I'm assuming that this is your pseudo-random timing to space out the packets. This is the usual way that a human will attempt to randomize packets like these. In fact, you are not randomizing, and will end up with overlapping packets based on the math. A better solution is to use the same timing, but use an offset to keep them apart.
It's easy to visualize that sending one packet at a 5 minute interval, and a second at a 10 minute interval, that these will overlap where multiples of 5 and 10 occur, which is every 5 minutes. Same thing happens with 26 and 32 minutes, except the overlap is based on when multiples of 26 and 32 occur. If you do multiple objects you get multiple?overlaps, with the occasional big cluster.
If you send all the packets at a 39 minute interval, but start them 4 minutes apart, they will never overlap. They will always stay 4 minutes apart. Some systems will support this spacing, others may not, so you are stuck.
Here's another thing to think about. Who is asking for the information you are providing? The basic concept of APRS is to send information periodically to keep the remote user's display populated. This works when there isn't a lot of information to convey. However as APRS is a 1200 baud channel, and has limited capacity, when lots of people send lots of information, collisions can wipe out data, making that data being sent useless.
One thing that was designed was a QRU server. This device is configured with a bunch of information, like objects for repeaters, gas stations, hospitals, etc that an end user can query when the information is needed. This however requires that the person needing the information has the ability and knowledge to know to ask the question.
All of the above isn't an admonition, or me trying to tell you that you are doing things wrong. Rather it is just a bit of information that *may* give a nudge towards looking at what you (and anyone else reading) are doing, and maybe think about doing that task a slightly different way. I know I can get stuck looking at a solution to a problem I am facing, and can't see any other perspective. But along comes someone else who asks "Why", and through trying to defend my position, or with the right outside prompt, a new and maybe better solution presents itself.
Carl