thought about this a bit...

I think the best solution is to propose (and have) a property for "GeoData type", based on existing classification generally used by the parser function for wikipedia coordinates:

https://www.mediawiki.org/wiki/Extension:GeoData#Parser_function

I'm not so enthusiastic about having some magic to infer type. I am sure bots (including mine, if needed) could quickly import / populate the types.

then, there are default dim values based on types:

$wgTypeToDim = array(

'country'        => 1000000,                                                                    
'satellite'      => 1000000,                                                                    
'state'          => 300000,                                                                     
'adm1st'         => 100000,                                                                     
'adm2nd'         => 30000,                                                                      
'adm3rd'         => 10000,                                                                      
'city'           => 10000,                                                                      
'isle'           => 10000,                                                                      
'mountain'       => 10000,                                                                      
'river'          => 10000,                                                                      
'waterbody'      => 10000,                                                                      
'event'          => 5000,                                                                       
'forest'         => 5000,                                                                       
'glacier'        => 5000,                                                                       
'airport'        => 3000,                                                                       
'railwaystation' => 1000,                                                                       
'edu'            => 1000,                                                                       
'pass'           => 1000,                                                                       
'camera'         => 1000,                                                                       
'landmark'       => 1000,

);

We could possibly supplement this with using the area (and length) property values, when available.

We could also potentially populate the country column for coordinates from P17.

For using geodata for rendering map features, I'd also want to know about P31 (instanceof), subclass and population, though not sure yet where I'd store them and think it's out of scope for now.

In T75482#1727589, @aude wrote:

@JanZerebecki type would potentially be used as a consideration for filtering and rendering map features at various zoom levels

Only potentially? So it is not used yet?

What are the intended use cases for the type, besides estimating dimenstion? What is currently using type?

Besides Daniel's question: I would very much prefer to not have this stored as statements on millions of items.

thought about this yet some more....

What we could do is have a "mapping" of the geodata types to P31 (instanceof) values and subclass values. This would prevent a proliferation of thousands or who knows how many instanceof types for geodata, yet use already existing information from items.

For example, Q55488 = 'railway station' and that has 90 subclass items. (e.g. "S-Bahn station", Q1793804). We could have a maintenance script (using the query service) that generates and updates these mappings between geodata types and instanceof values.

The type to P31 mapping would be configuration, so we don't hardcode this knowledge in wikibase. The mappings could be stored in a database table and cached somewhere (memcached?) or depending on how large the mapping is, maybe file-based caching, APC, or something?

If, at some point, we wanted to add more geodata types, then I think it would be easy enough with this approach to do so.

For dim, we can default to the type-to-dim mapping, but perhaps if an item has the area property set, length (e.g. for a river), or northern/southern/eastern/westernmost points, then we could use those for dim.

this is not a blocker to Special:Nearby but is still something we should do soon, in order to make GeoData on Wikidata more useful.

This type classification is not used anywhere, not even as a filter for results from the API, from what I heard.