Talk:Telcom
29.07. Jens David, in the very beginning the call name and sign were part of contact details. This was rejected with arguments we found interesting enough to follow. 'thinking we need those information in any way. It is only the question where to place. I am still the opinion that contact details is a good home for them. This is the advantage of having all together; see any List of Radio Signals for a check where they all are listed as contact details.
29.07 By David. I know that we have been round this buoy before and you nicely got us out of the last big hole by proposing condet. I was thinking earlier this morning that all the detail in condet is new i.e. it is not in S-57 to date. If we now include the "old" stuff in condet, for the very good reasons you suggest, we may find that we are opposed by those who do not like the possibility of two approaches to encoding and I feel that we will be opposed rather more strongly by offices who may feel they have to change their current ENCs to remove COMCHA and CALSGN from RDOSTA, and perhaps elewhere, in order to populate condet. Taking the more conservative approach would allow us to add in the extra value in things like phone numbers and street addresses without disturbing the current S-57 structure.
I think that this also follows our basic phylosophy of using what we can from S-57 and only building new where we have to.
I do like the tidyness of gathering together all these details but will this bring any more than tidyness? Or to put it another way, is there a technological or systemic benefit from putting all these attributes together in condet?
30.07. By Jens. Although I definitely like the condet ideas I thought once again about our positions and it seems to me it is only a question of "How to feel"; not really an opposite position. You know, the advantage of having a head like a ball, the thoughts can change the directions.
As far as I remember S100 will be backwards compatible. Means, all information currently stored in an ENC will stay valid. S100 also does not required strong bindings between obj/attr/attrID; see register and registry procedure. What we are proposing is a set of information useful in the combination provided. The thoughts about the right set of information is essential. IMO it is the only way to check whether our new ideas meet the reality. And it is also essential for creating using guides, portrayal guides etc. This set can be extended by other attr./attr.ID if needed. That again raise further questions related to our work.
1. Is the information provided useful? if yes ok, if not go away.
2. Is the information needed? if yes ok, if not go away.
3. Do we produce the risk of duplicated coding options? if yes go away, use the existing code, if not ok
4. Do we provide clear definitions? if yes ok, if not improve it
Answering the questions in a convenient way for all shows that we are on the right way. What do my arguments mean for telcom? If we write a coding guide in a way making clear that each authority with radio communication (tx/rx or both) facilities is also a radio station (which is not really difficult) than I agree. We can deleted telcom and add the calnam to RDOSTA.
If not, we should discuss again.
In any case, to be deleted or not, we should create a home for deleted entries. I will insert a sub-page for them at out FDD start page. Otherwise we go the risk to loose them in the deep of the database.