Administrative division

[astotrzynascie]

Release v2024.06.02.1, Windows + Meson + MSVC, used latest wrap files (including Pango), using Cairo backend.

Imported using default file (map.ost), so types like boundary_country, boundary_state, boundary_county, boundary_administrative (WAY, AREA) or place_state, place_region, place_county (NODE, AREA) should be in the database.

Defining in oss file

	[MAG world-]
		{
		[TYPE mentioned_any_boundary_or_place_type]
			{
			WAY/AREA/AREA.BORDER/WAY#outline { color: #ff0000; displayWidth/width ...; }
			}
		}

has no effect, no administrative division is visible.

Edit: country-level databases from Geofabrik.

What am I missing?

[Karry]

can you share your complete style file please? are there any warnings during stylesheet initialization?

[astotrzynascie]

No warnings.

I merged all files, tested that it still works (and still no administrative divisions) and changed extension from oss to txt.
Tests start around line 1650.
I have a more questions, nothing big I think, should I ask them here (in 'by the way' mode) or start a new topic?
dark_wip.txt

[astotrzynascie]

More info / questions:

• if I cut down oss to boundaries only, the map is empty;
• boundaries.oss isn't working either;
• during import, at step 6(?) I get a lots of warnings:
  WW Ignored boundary relation role 'subarea' in relation <number> boundary_administrative
• why this doesn't show any cities at any zoom level?

[MAG 0-]
	{
	[TYPE place_city]
		{ NODE.TEXT	{ size: 1.0; color: @labelColor; } } // tried priorites (1), but with no luck
	}

• it would be nice to have DOUBLE/UDOUBLE to use in CONST (general "dim level" for lighten/darken for example);
• for comparison I used libosmscout from vcpkg, and even if I saw that Pango was processed, the maps (through Cairo) are really ugly; I used default distribution, any chance that somehow forcing vcpkg_full.json would change it (or anything else)?
• the only way (I know so far) to get labels wrapped is to make them autosize (only works for areas), any other way to wrap long names?
• is the order in .oss files important? I don't think it matters for types (I mean, if we have TYPE building_garage - which is, as I understand, also a generic building - and TYPE building, and set color for garages first, the color for 'generic' buildings won't overwrite it), but doesn't it matter for any other feature?
• silencing osmscout::log is not working for 'loading image' messages :(
• and a bonus question: I removed OPTIMIZE_LOW_ZOOM from wood type, but it didn't change anything when it comes to the visibility of wood areas at very low zoom levels; how can I make them visible (and looking nice) at all zoom levels?

[Framstag]

@astotrzynascie : Sorry for not seeing your questions earlier. I try to answer at least some:

• The vcpkg-XXX.json controls which dependencies are build (and thus used) using vcpkg under Windows (using Visual Studio). This was necessary, because build time will drastically increase dependening on the dependencies you build using vcpkg. For example Qt builds alone will take a while. Since this is not feasable under GitHub, we created variations. Also some dependencies are possible to use and Windows but you likely may not needs them. It may make sense, to create your own variant of a vcpkg.json file, based an the full version for you needs.
• Label wrapping: There are options in the MapParameter for this, it is not in the style sheet:

    size_t                              labelLineMinCharCount;     //!< Labels will be _never_ word wrapped if they are shorter then the given characters
    size_t                              labelLineMaxCharCount;     //!< Labels will be word wrapped if they are longer then the given characters
    bool                                labelLineFitToArea;        //!< Labels will be word wrapped to fit object area
    double                              labelLineFitToWidth;       //!< Labels will be word wrapped to fit given width in pixels

• Order of OSS: It may be relevant (something I need to test). If for example zoom intervals overlap, the order of declaration may be important

• Logging: It is possible that some output does not use the logger. This would be a bug. Please give more details for a fix.

• OPTIMIZE_LOW_ZOOM only means that further "crunshing" code is used to keep rendering fast. Visibility is an OSS problem.

Currently wood are rendered starting a certain zoom level only:

  IF wood {
    [MAG stateOver-] {
      [TYPE wood] AREA { color: @woodColor; }
    }

    [MAG detail-] {
      [TYPE wood] {
        AREA.TEXT { label: Name.name ; priority: @labelPrioNatural; color: @woodLabelColor; autoSize: true;}
      }
    }
  }

• boundary relation "subarea". The OSM format is very flexible, we do not always support everything that is possible to model.

• City not shown: In principle they should get shown, but we do not render overlapping labels. It should work with high enough priority. See place.oss are give an concrete example to reproduce.