mapshaper icon indicating copy to clipboard operation
mapshaper copied to clipboard

Additional attribute for SVG output

Open mkilinskidev opened this issue 7 years ago • 7 comments

Hello. I would like to export SHP file to SVG with additional attribute in path tag. I need to have a path tag with id and name fields. There is a export parameter like id-field=XYZ but is there any option to export file with name attribute?

mkilinskidev avatar Jul 27 '17 08:07 mkilinskidev

I think this feature would be simple to add... one way would be to add an option to the output command, say, svg-data= or attribute-data=, followed by a list of fields to add as attributes. To create a name attribute, you would go: -o svg-data=name out.svg (assuming your dataset already has a field named "name").

There's one thing I want to discuss -- mapshaper translates "MultiPoint" data into multiple <circle> elements inside a <g> element, and adds the id (if any) to the <g>. Single point features are not wrapped in a <g> element (example is below). Do you think that attribute data should be assigned once to the <g> element of a multipoint symbol, or should it be duplicated in all of the <circle> elements?

Sample SVG output for a single point feature and a multipoint feature:

<circle cx="599.5" cy="200.5" r="3" id="A"/>
<g id="B">
<circle cx="599.5" cy="200.5" r="3"/>
<circle cx="799" cy="1" r="3"/>
</g>

mbloch avatar Jul 27 '17 14:07 mbloch

This seems like a very useful feature. Would you like me to take a look at it and submit a PR?

In my opinion, attributes should be assigned once to the <g> element in the case of MultiPoint features.

It would also be useful to have the option to export all attributes, maybe svg-data=all or specify which fields to exclude, rather than naming all that should be added, but that doesn't seem very important.

SLeitgeb avatar Mar 28 '19 12:03 SLeitgeb

Before we write any new code, I have a couple of questions.

For storing ordinary data values in SVG elements, there's the 'data-*' naming convention, which looks to be part of the SVG 2 spec. There seems to be support from some but not all current browsers. Should data exported using -o svg-data= apply the 'data-' prefix to field names?

See: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/data-*

Some users will also want to export predefined SVG attributes, like "fill-opacity" and the other presentation attributes. Should there be a different option for exporting predefined attributes, say -o svg-attributes=* ? This option would assume or require that the exported fields have valid attribute names. It might be nice to print a warning if we think a field does not have a valid SVG attribute name.

mbloch avatar Mar 28 '19 15:03 mbloch

I would most definitely go with data-* naming convention (forgot to mention this in the previous comment), in this case we would most likely always avoid attribute name conflicts. With this approach, it's also clear which attributes contain the attribute data.

The idea to export SVG attributes from attribute fields is great, it would also allow the user to export attributes not following the data-* scheme. It's also possible to rename the fields with -each, so there's probably no need for field → attribute mapping.

Should there also be some kind of automatic field name conversion, e.g. "Birth Rate" → "data-birth-rate"? There could also be issues with diacritic and other characters not matching the allowed characters. Warnings are desirable to avoid confusion around this.

SLeitgeb avatar Mar 28 '19 16:03 SLeitgeb

Seconding this idea. For situations where I like to manipulate SVG directly in the browser, having a data-* attribute (or an arbitrary one specified by the user) is useful. And being able to bind multiple attributes would be great. Right now my workflow involves:

  • assigning an id like -each 'id = NAME' -o id-field=id format=svg
  • opening the file in a text editor and replacing all id tags with data-id (because it's entirely possible for an svg to have more than one node that gets assigned with the same id and this isn't legal according the HTML spec)
  • running a custom JS script that loads the nodes as an object and appends additional data-* fields as defined in a csv.

jwhazel avatar May 23 '19 22:05 jwhazel

I just released a new version (0.4.117) that includes the -o svg-data= option, which takes a comma-separated list of field names. This option exports data as data-* attributes.

There are restrictions on data-* attribute naming. For example, capital letters are not allowed. I thought about automatically renaming field names, but decided instead to skip fields with non-conforming names and print a warning instead.

data-* attributes are part of the (still unratified) SVG 2 spec. Some SVG parsers might throw errors. Browser support seems good (link)... not sure about IE though.

mbloch avatar May 28 '19 00:05 mbloch

I thought a bit more about field renaming. It's very common to have capital letters in field names, and it would be a hassle to rename fields just to be able to export them as SVG data. I think mapshaper should apply some simple renaming rules, like in @SLeitgeb's example above ("Birth Rate" → "data-birth-rate"). Field names that need more complicated renaming will have to be renamed manually (e.g. names containing non-ASCII characters, or names that start with a digit).

I'll plan to add renaming to the next release in a few days.

mbloch avatar May 29 '19 15:05 mbloch