a) Yes. The renderer places the symbol at the centroid of the area. Many lighthouses have been mapped this way - when the actual building outline was mapped, the mapper often transfered the tags from the original node to the (closed) way or multiploygon.
b) Yes. Sectored lights must have a subscript, even there is only one sector. Very often a single sector is inferred by partial obscuring of an otherwise all-round light. Please do not do this as it makes for a very untidy map. Instead tag it as "seamark:light:visibility=part_obscured" + "seamark:light:information=*" with the details of the visible or obscured arc(s). In other words, only use sectors where there is a navigational intent for the sector arc & not some artifact of the light's siting.
The following was posted to the OSM talk list:
"The SotM accommodation deal is a really good one but we do have a limited number of rooms so I encourage you to book up early. As noted the ticket sale will follow shortly and will be a similar price to Birmingham 2013.
Community accommodation ideas:
http://wiki.openstreetmap.org/wiki/Stat … unity_info
We work hard to keep the cost as low as possible and the main way we do this is through sponsorship. If you or someone else is interested in sponsoring SotM 2016 please contact the team on firstname.lastname@example.org"
I have made my booking & will be arriving in the afternoon of 22 Sep & leaving on the morning of 26 Sep. Hope to see some of you there!
I have just published a beta version of the new renderer in its JOSM Imagery Layer plugin form. Please try it out and report any problems, either by opening a ticket here: https://github.com/OpenNauticalChart/S- … ite/issues or a post to this thread. Please provide an OSM file that will cause the problem. If JOSM reports an unexpected exception, please also provide the console output.
To install the plugin, refresh your plugin list and look for "SeaChart" and install it. It is invoked by selecting "SeaChart" in the imagery menu.
The renderer is about 90% complete. Yet to be added are the Brazilian notice marks. You may see some erroneous artefacts in the land area rendering - this is a known problem that I will defer until all the seamark layer rendering is complete.
OK, given this experience, I could instead generate a set of tiles of zoom-12 size. This would reduce the tile size to ~100kB, but not take up much more space on the server. For lower zooms, I could make a set of sea-, river-, lakes- and land-only tiles at zoom-9 size (these would be much smaller as most of the content of the full-feature tiles is roads, railways, man-mades & landuse). I could also do a set of land- & sea-only tiles at zoom-6 size.
I have started rendering the SVGZ tiles & uploading to the OSeaM tile server. You can find them at: http://tiles.openseamap.org/int1base/<x>/<y>.svgz where x & y are zoom-9 tile numbers. As each tile covers a zoom-9 area, to display at other zooms they will need to be scaled by a factor of 2^(z-9).
Both Olaf & Axel have said that they will work on a base layer using these tiles.
Happy New Year to all!
You can look at Gabi's solution at http://openseamap.he1ix.org/map.html
Nice styling of the control buttons.
and Dirks solution at http://maps.grade.de/ol3.html
Good presentation of background maps - they are not as intrusive as the raw OSM map
Object query gives raw tag values - a non-expert plain language mode would be good.
Neither have a lat/lon grid or an edit button - the most important one for mappers!
I do not know about his change-set routines ...
The shell scripts are also in the renderer repository: https://github.com/OpenSeaMap/renderer/tree/master/work
I believe that Olaf was only referring to his Online Map re-write, rather than the entire ONC project. Unlike OSeaM, all developers registered on the ONC Github are co-owners and can therefore create new projects, submit pull requests and open issues on all projects or become a team member of a project.
- adding and maintaining links to OSM-db will be a pain
- this also applies to seperate 'harbour-db'
A link only has to added once, whereas the data linked to will be constantly changing. Also it will not be us who add these links - it is the DB operators who would be encouraged to do that work.
- click on harbour icon 'Alter Hafen Wismar'
- pop-up key=value box
- offer 'search skipperguide' button/link
Remember 90% of viewers are not mappers - they will not understand keys and their values. Any pop-up box must translate key/value pairs to plain language.
The scheme has to be global, whereas the various harbour DBs only have local extent. Therefore offering specific DB buttons would not be a workable scheme.
If we were to have tags of the form: website:<DB name>=<DB URL>, then harbours/marinas/anchorages with these tags would present the link(s) in the pop-up.
The best way to do that is to add links to the various marina guides to the harbour object. That way, clicking on the link (which also would have to be displayed in the pop-up panel) will take the user to the up-to-date entries in those guides. We can then encourage to operators of those sites to add the link tags in the areas that their guides cover.
We don't have to - Olaf has a much better scheme & it is visible right now. Find a harbour or marina and click on it - details will appear.
The OSeaM scheme was to try and import & merge data from disparate sources, most of which provide inadequate details or poorly located positions. The problem then remains how to maintain this data? When the original sources are updated, our import would become stale, so requiring constant re-importing and editing. Nobody has time for this!