New text placement algorithm gives an error #494
Comments
|
It looks like adding the value is needed in proper https://github.com/mapbox/carto/tree/master/docs/api/mapnik and even this version lacks http://mapnik.org/mapnik-reference/#3.0.20/ @talaj Could you update Mapnik API documentation to include it? And is there a simple way to compare the difference for example between 3.0.6 and 3.0.20 to produce new |
|
@kocio-pl I've updated the documentation in mapnik/mapnik-reference#149.
I put that .rst file to https://gist.github.com/talaj/bcf03fe9a3912ce42ab246a769e443b8. I've generated it by pointing to the latest mapnik-reference: diff --git a/package.json b/package.json
index 06bf606..a641771 100644
--- a/package.json
+++ b/package.json
@@ -37,7 +37,7 @@
"hsluv": "~0.0.1",
"js-yaml": "~3.10.0",
"lodash": "~4.17.2",
- "mapnik-reference": "~8.8.1",
+ "mapnik-reference": "git+https://github.com/mapnik/mapnik-reference.git",
"semver": "~5.5.0",
"yargs": "~11.0.0"
},Then I made: $ npm install
$ node docs/generate.js |
|
@talaj mapnik-reference needs a new release. An up to date documentation is not enough for carto since it also has to use an updated mapnik-reference. For stability reasons I will not switch to master of mapnik-reference. Once there is a new release of mapnik-reference carto can be updated. @kocio-pl I just said that carto didn't need any update in its code. But it still needs an up-to-date mapnik-reference. For that an 1.1.0 release of carto is necessary. |
|
@nebulon42 OK, I can do it if you don't mind. I would also like to rebase and merge those two pull requests there. |
|
Great! I just wanted to be sure that there won't be some unforseen problem that wouldn't allow to use grid in OSM Carto and no one will touch CartoCSS. This one is unforseen indeed, but if you're going to fix it, it's not really important for me if it's in the code or in documentation. |
|
@talaj I have created releases of mapnik-reference in the past, but I'm no longer able to do it since I have removed myself from the organization when I stepped down from maintaining openstreetmap-carto and Kosmtik (and I actually also want to step down from maintaining CartoCSS). So I don't mind, no I highly appreciate it if you do it. :) If you cannot publish on NPM because of lacking rights I still can do that because I still have the rights for it. |
|
@nebulon42 I've cut a release v8.9.0 of mapnik-reference, but don't have rights to publish the Node package. Can you please do that or can you give me rights to do that with simple description how to proceed? |
|
Thanks! Looks like I can grant you rights on NPM for mapnik-reference, but you would need to create a user at https://www.npmjs.com/ and tell me its name (also per mail if you like, mail addr is in my profile). There is https://github.com/mapnik/mapnik-reference/blob/gh-pages/contributing.md which has the steps in it. Basically it is just |
|
What do you think about granting permissions to my account (kocio-pl) too for respective npm and GitHub repos? My work at OSM Carto relies on these tools and packages and CartoCSS doesn't seem to be actively maintained by a healthy team any more. |
|
This was not about carto but about mapnik-reference. I'm happy to accept new maintainers here, but they would need to do some work in the form of PRs/patches first as it is the case in almost all open source projects. You might still get some rights granted if you contact Mapbox directly. |
|
There's a long chain of interdependencies, including code, but also releasing, packaging, releasing packages, deployment rules (see gravitystorm/openstreetmap-carto#2962 (comment))... I took it for granted, until fixing problem with label placement took almost a year because of these inter-project dependencies (and the code itself was fixed pretty soon!). Now I'm aware that some parts (like CartoCSS) are not maintained in practice, and there's another unexpected repo/package in this chain, I'm beginning to really worry. In case of non-maintained things (in practice) I'd like to play a role of accidental (backup) release manager, to avoid problems with multiple points of failure in the chain. It's hard for me to imagine typical patch/PR work that can be done - this is what works when the project is still alive. I don't want to be a coder and add functionalities myself, just to keep the chain alive and updated. But if you find some task that I could prove that I won't screw the project, I'm ready to learn and do it. It all might sound like a hollow fear, but my experience says that it's good to avoid problems as soon as they become probable, like 1 person active on the deck. This is for example how I became forum admin after one person keeping it became inactive without try to pass it along. It took months for OMSF to get in touch with him and migrate the forum to a community curated space - and it was not even hard "hit by bus" problem, because he was reachable eventually... Now we have 3 persons team there and it's safe for me. This is kind of problem nobody talks about. People are mostly voluntary working on a single project or two, but OSM ecosystem is sometimes big and connected in multiple ways. The problem in one point can hurt another one in strange ways. Until there are multiple persons, it is less of an issue, but at some point nobody even knows how the real pipeline looks like, let alone has all the tools to fix if something is broken. I'm aware this is not easy thing. That's why I ask you what do you think would be safe to do to avoid such problems. Granting permissions is just how I think it could be done, but maybe there's some other way for community to not fall into trap of single project problems influencing the rest of ecosystem. You're not active, but I can still talk with you, which is kind of red light flashing situation for me - small failure warns us about possible future problems. |
|
I think I made it clear: If you want to become maintainer start submitting patches. Otherwise please stay on topic. |
|
Do you think it's better to open another ticket to talk about such project issues? I have some questions about it and I'm not sure where to go with them. |
|
Yes, please. Questions about project governance should go into another ticket. |
|
I have published mapnik-reference v8.9.1 finally. I had to make a new minor version bump as I did not correctly update datasource templates previously. Carto tests are passing against this version. |
|
I have updated mapnik-reference, generated API documentation and released v1.1.0. |
|
Thanks for both of you! |
|
BTW - there's another Mapnik documentation update (mapnik/mapnik-reference#151), which might need another packages update to avoid errors with |
Mapnik 3.0.19+ adds new new text placement algorithm -
grid:https://github.com/mapnik/mapnik/blob/v3.0.19/CHANGELOG.md#3019
CartoCSS gives an error when it is used and does not produce XML configuration file. I checked it with 0.18.2 and 1.0.1, here's a 0.18.2 error output, since it gives more debugging details:
See also gravitystorm/openstreetmap-carto#1391 (comment).
The text was updated successfully, but these errors were encountered: