You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can split the command-line parameters into two groups - those that a given style needs to have set, and those not relevant to the style itself.
For example,
--extra-attributes, --multi-geometry, --keep-coastlines, --hstore might be required by a style
--num-processes, --unlogged, --input-reader, --cache have no influence on the output.
Styles currently need to have a readme entry stating which particular flags need to be set, otherwise the user will find a non-working system after hours of importing data. Users also need to know enough about how osm2pgsql works in order to successfully merge those options with other ones that they've read elsewhere, usually regarding optimisations.
So a better solution would be to allow the style to control the switches, ideally by extending the standard foo.style osm2pgsql config file.
The text was updated successfully, but these errors were encountered:
I can split the command-line parameters into two groups - those that a given style needs to have set, and those not relevant to the style itself.
For example,
--extra-attributes
,--multi-geometry
,--keep-coastlines
,--hstore
might be required by a style--num-processes
,--unlogged
,--input-reader
,--cache
have no influence on the output.Styles currently need to have a readme entry stating which particular flags need to be set, otherwise the user will find a non-working system after hours of importing data. Users also need to know enough about how osm2pgsql works in order to successfully merge those options with other ones that they've read elsewhere, usually regarding optimisations.
So a better solution would be to allow the style to control the switches, ideally by extending the standard foo.style osm2pgsql config file.
The text was updated successfully, but these errors were encountered: