> > > In either case, how will you go about it? > > Will it work on mapnik XML style sheets, or carto CSS ones.....or maybe > the > > CSS style used by KothicJS and others? > If we take entries from users into database, then we can generate any > type of file from database. > XML or CSS by fetching all the variable values from the database. > I am not sure where the database idea comes into it - the xml style file is very complicated - are you proposing to include all the parts of that in a database to re-generate it? Kompza also mentioned a tool to convert between style types, which would be worth looking at.
> > Therefore one possibility may be to use tilemill as a > > base for the project. > Is it mean to do improvements in tilemil? I haven't really thought about it, but thought that if you want a graphical style editor, tilemill does a lot of that, so you might be able to build on it rather than start from scratch. > > > The simplest step forward, which I think would be useful would be to > extend > > the use of entities in the existing XML stylesheet so that all of the > styles > > for drawing the various components are defined in a single place, > separated > > from the more complicated bits, > > but I have not looked at how feasible this > > is given the support for various zoom levels in the style sheet - it may > not > > be much simpler (but could maybe have a file for each zoom level?). > > Not got this point, Can you please elaborate it a bit more? > I think it is a bit simple for what you have in mind, but XML allows you to define entities (~=named constants as far as I can tell). Look at the main OSM style - there is an inc/entities.xml.inc file that defines quite a lot. I was wondering about parameterising it so we have a single '.inc' file that defines the road widths, casing widths, colours etc. in a simpler looking file. Again, I have not looked at how much simpler this would make it, because it may be complicated by the number of different zoom levels. I guess you could do it for colours very easily, but road widths could be harder. Once you have got all of the information that a casual user is likely to want to modify in a single, simpler looking file, it would be less daunting for a non-technical user to update it. There is not a lot of 'code' in this idea though, so it may not be a good GSoC project on its own, unless it were linked to something else to make it easier for users to make their own maps. > > -- Graham Jones Hartlepool, UK.
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
