[OSM-talk] Maritme borders
grand.edgemaster at gmail.com
Mon Feb 9 18:30:31 GMT 2009
2009/2/9 Jochen Topf <jochen at remote.org>:
> On Mon, Feb 09, 2009 at 05:20:51PM +0000, Thomas Wood wrote:
>> I see no reason why the relation model cannot apply with a tagging of
>> boundary=maritime on the maritime sections of the boundary.
>> The required ways will still be retrievable from a (correctly
>> produced) relation, so the primary concern of the tagging of the ways
>> should be for renderers (and certainly in Mapnik's case, keeping the
>> tagging simple greatly simplifies the implementation - messing around
>> with specific relations just to determine the maritime status of a way
>> is messy).
> Simple rendering without need for the relation has been taken care of
> in the comprehensive proposal by tagging the ways with admin_level. What
> else do you need?
>> I also think we should keep boundary=administrative for 'confirmed'
>> boundaries, the territorial waters maritime boundaries is (currently)
>> defined from OSM's view of the country's coastline, so may not be the
>> definitive boundary.
> There is nothing "confirmed" in OSM anyway. Land and maritime borders are
> like everything else we have from some unknown source of questionable
> validity. :-) I see no difference here.
>> Maritime borders are by their nature different from administrative
>> borders on land, so I think that using boundary=maritime rather than
>> boundary=administrative maritime=yes (or other suggested options) is
> Why are they different? I don't see that.
> Adding new tags (here boundary=maritime) always has a cost. Every
> software that wants to do something with the data has to know about it.
Some software will want to differentiate, most will not require the
maritime borders by default. Most will only care about the land
boundaries and coastline, as most other world maps use.
If they have a need for maritime boundaries, then do a select on
boundary=maritime, or even just boundary=*
boundary=maritime opens up the possibility for a logical ordering of
boundary_type=eez etc. Or, we could extend admin_level to it, but
admin_level as it is is a little untidy.
More information about the talk